Question

I have been told by another fellow C programmer to write large applications in several different .c and .h files, and then compile them together. They say it will run faster.

Does a multifile application run faster than a singlefile one? If so, what makes it run faster? Also, what other benefits are there to multi file programming?

Which platform(s) does multi-file C programs affect performance?

  • Will a multi-file Windows application run faster than a single-file one?
  • Will a multi-file MacOS application run faster than a single-file one?
  • Will a multi-file Ubuntu application run faster than a single-file one?

No correct solution

OTHER TIPS

There are a lot of technical reasons behind using multiple files when writing large complex systems. All of them are meaningless in the face of the best reason to use multiple files:

Readability.

When I write code that resides in one file I'm presenting what you need to understand to follow how this part of the system works. Every detail not in this file is abstracted away, represented with a good name that should ensure you can still understand what is happening here without poking your nose into the other files.

If I've failed to do that I've written crappy code and you should call me out for it. In cases like that multiple files rarely do you any good.

Without that consideration I can write the whole program in one file. The CPU wont care. It will just make humans miserable when they try to read it.

The traditional technical reason is to separate code into independently deployable units that can change without having to redeploy the whole system. There are cases where that's very important such as when your software is burned on many chips and you don't want to throw away all the chips just because one needs to change.

It's also true that being independently deployable allows compiles to go faster since you only have to recompile what changed.

Even in those cases though, I'd still argue that the biggest benefit is creating a boundary that limits what you expect your readers to hold in their head at any one time.

TL;DR If multi file programs annoy you because you have to keep looking in multiple files to understand them you're simply looking at poorly abstracted code with bad names. That shouldn't be what it feels like. Each file should tell one story from one perspective.

The question falls into same category as why buildings are not build from one piece of rock but a bunch of bricks?

Answer:

  • easier to navigate than scroll through one huge file
  • make recompile works only on files related to the change
  • various parts of the program can be programmed by different people
  • code from some files can be put into libraries for future reuse
  • at compilation time an error will indicate in what file the problem is (easier to find)
  • at compilation time compiler needs much less memory (less requirement to hardware)
  • at compilation time easier for compiler to analyse the code (faster)

This is just from top of my head -- there are definitely more benefits in store.

The other answers are fine, but something they're missing is actual technical limitations.

For example, you can't actually save all of the code for my day-job application in one file - it's bigger than the file size limitations of common file systems. That sort of size also wreaks havoc with editors and compilers and linters since the syntax tree for that code is even larger! And then you get to source control and diffing tools trying to work on dozens of gigs of text in one sitting. Since you're working in C, you also need to worry about your actual binary size. Most OSes have an executable size limit separate from the file system size limit.

This is an outlier of course. Multiple files is primarily to make programmers' lives easier, but I hope this gives you a better feel for what "large applications" can entail.

I have been told to write large applications in several different files. They say it will run faster. What makes it run faster?

Also does a multifile application ACTUALLY run faster than a singlefile one

In C, there is no reason to assume that a multi-source-file application will run faster, and several reasons why it might be slightly slower. Use of multiple files is for the convenience of the developers.

There are even some build systems which let you write multiple files which are combined into a single huge file before being passed to the compiler. This may be called "unity" or "amalgamation" builds.

The main reason is inlining: replacing a call to a function with a copy of the function. C will not usually inline functions from different source files unless the linker is configured to do so. This feature is called "link time optimisation" in GCC.

Other commentators have mentioned the idea of not loading unused bits of the program. However, the function grouping provided by the source files may not be preserved in the executable; unless you're using an "overlay" system (mostly obsolete), or you have separated some features into "plugins.”

On Linux and other systems with virtual memory, the operating system can unload unused parts of the program on its own.

There are also some minor benefits possible from things like string constant deduplication - again, you can have the linker handle this, but it may not be on by default.

Build speed issues are worth considering. If you split a program into N files, where N might be in the 100-10,000 range, then compiling one file is usually much quicker than compiling all N files. However in some cases gathering all N files into one huge file is faster than compiling them all separately - provided it doesn't crash the compiler. This tends to be more important in C++ where compile times can be much longer.

In practice, developers split source files because it makes them easier to work with. Opinions vary but 1,000 lines is a good guideline number to start considering splitting a file.

Advantages of using multiple files for a program are numerous.For instance:

  • if you write code for a class in a separate file, you can use that class in multiple programs. It increases reusability of the code.
  • Furthermore, if you want to change anything in a class, you will only have to change it in that particularly file and the change will be automatically reflected in all the projects referring to this file.
  • Furthermore, it is advisable to write large complex programs in multiple smaller files.
  • And last but not the least, in large organizations, several programmers are working on a project. In such scenarios, each programmer is responsible for designing designated modules; therefore separate files for each programmer, are convenient to code and then subsequently integrate.

You can find more arguments in this article.

Another significant reason to use multiple files that somehow no one has mentioned:

When you work on a software development project with a team, it is very common to use a version control system such as Git. One major hurdle faced by any VCS is merging the work of multiple authors. If you and another developer work on the same file at the same time, your work eventually has to be merged together. In some cases, you may both edit the same part of the same file, which can lead to merge conflicts: situations where the VCS can't automatically determine how to merge the changes, and a human has to do it manually.

When all of your code is in one file, there's an increased risk of merge conflicts. Anyone who is working on the code is working on the same file. This increases the likelihood of editing the same code at the same time or otherwise stepping on each others' toes. Even someone who is working on a different part of the file might inadvertently do something that interferes with your work. For example, they auto-format the entire file, rename a function you're editing, reorganize the code and move functions around, etc.

Breaking the code into logical systems split across multiple files reduces the risk of merge conflicts caused by multiple people working on the same file at the same time. It also makes it easier to resolve merge conflicts, because less code in each file means smaller conflicts that are easier to resolve.

Here's a worst-case scenario which I've unfortunately encountered before: you have a 10,000 line file, which Tom and Sally are working on. They each spend several hours making extensive edits to different parts of the code. At some point, Tom notices an indentation mistake and habitually presses the "auto-format" hotkey, which changes the indentation, line breaks, etc for the entire file. Later, when they both go to commit their code, a merge conflict occurs because Tom's auto-format changed nearly every line of code in the entire file and the VCS can't figure out how to merge the changes. Either Tom or Sally has to now spend hours of time manually merging 10,000 lines of code together. If the code had been split into multiple files, they might not have had a conflict at all, and even if they did it would not have affected the entire codebase.

In general it depends on the context. In addition to the other answers in javascript, python and other languages I am probably not aware of a file imported is loaded only once. Let us say f.e. we need to import a file with 150000 words , which needs approximately 1 sec to be loaded to a variable(or data structure). And then we want to use this file to find if a word is in these 150000 entries. We also need to rerun this whole process 1000 times which means about 1000 seconds needed. However, given we import the 150000 entries file as a variable from another file the whole 1000 steps process lasts about 1 second.

However, please bear in mind that the rest of the answers provide a much more significant reasoning to your question.

While the program will run at the same speed whether it's one file or one thousand the editor is quite another matter.

Intelligent editors bog down when the files get large. I find it noticeable on any form with a lot of UI elements in it.

Even when we have complex code navigation tools like Jump-to-Definition, organizing your project in a tree of files and folders makes it easier to onboard new developers. It makes it easier to find which file you need to start working on a feature.

As for the "faster" concern, most modern compilers support LTO, so even if you use separate compilation units (speeding compilation during debug), the resulting executable will run at the same speed when LTO is turned on.

A lot of it just comes down to:

  • You want to be able to easily navigate to different logical parts of your program, and view those parts side-by-side
  • it's easier to create an IDE/programming environment that deals with those separate parts as separate files than it is to create an IDE that keeps all the code for a program in one big file, and has to show parts of that file side by side, etc.

In many cases there would be absolutely no problem in having all your code in one real file on disk if your IDE was easily able to help you navigate around that file, and show different parts of the file side-by-side.

Licensed under: CC-BY-SA with attribution
scroll top