0

The follow files:

1.cc include common.h 
2.cc include common.h
unity_build.cc include 1.cc and 2.cc

I can understand that the time to compile unity_build.cc will be faster than compiling 1.cc and 2.cc separately, because common.h is only expanded once, so less code needs to be compiled in total.
But why the binary file size is smaller? Didn't the linker remove the same symbols?

Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312
zcfh
  • 101
  • 1
  • 9
  • 1
    "faster" / "less code" than what? You seem to compare it to something without saying with what you compare – 463035818_is_not_an_ai Jun 13 '23 at 09:41
  • What size do you compare? File size of the binary? Code size? Compare with what? BTW: A symbol in one compilation unit is not the same as a symbol with the very same name in another compilation unit. – Gerhardh Jun 13 '23 at 09:53
  • "File size of the binary" – zcfh Jun 13 '23 at 09:55
  • 1
    Perhaps because with unity build you are essentially automatically getting Link Time Optimization + less TU statics. – user7860670 Jun 13 '23 at 10:00
  • What confuses me is the difference in the size of the linked binary using unity build, not the time – zcfh Jun 13 '23 at 10:01
  • Link Time Optimization is a size+performance optimization which happens during *link time*. I guess this is one of those confusing english wording. S.A. https://stackoverflow.com/questions/46319579/what-are-the-drawbacks-of-single-source-project-structures/46321758#46321758 – user7860670 Jun 13 '23 at 10:03
  • 1
    the file size of the binary is not the size of th binary itself. The files also include debug information, linker infos and a lot more. To compare the real executable part in the file, you have to use e.g. `size ` on linux/unix. – Klaus Jun 13 '23 at 10:12

0 Answers0