4

I'm sure the folks at Google worked long and hard to ensure the programmer wouldn't have to worry about details like this, but I'm curious.

In Go if I have multiple files in the same package, but they all import the same file, is this more or less efficient for the compiler than one large file with a single import? Or does it not matter in the slightest?

2

It doesn't matter.

Parting a package into multiple source files is something for you, to organize your code better. But to the Go compiler it doesn't matter. If you have an unexported identifier in one source file, you can use that in the other source file (same package of course) without any notice (like import). What matters is that your package will have a dependency on the other package.

Note that it affects compilation efficiency in the slightest way: the compiler will have to process multiple files, create multiple internal data structures (required only for compilation), process the same sections (e.g. import) multiple times. But this should never affect your judgement to choose 1 file over multiple. Just some self made-up numbers to help understanding it: does it matter if your package with 1 source file compiles in 100 ms or it takes 100.1 ms if it is broken into 5 files? No, obviously.

Going further, compilation time should also not be a factor even if it is much bigger (like 1 sec vs 2 sec). Compilation time and run time efficiency are 2 different things, the latter is what should concern you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.