3 ms·

They mentioned compiler flags, so my guess would be that they were doing something like tightly packing structs in the release build to lower memory usage or so

• saagarjha 6y ago
  Or the opposite, as packing usually requires slower, unaligned accesses.
  • sumtechguy 6y ago
    That would depend on how much that struct is created in memory vs the total code that uses it. If you have one instance in memory then yeah the code is probably bigger and slower (depending on arch). But if you have thousands of the structs in memory the speed and code size trade off may be worth it on a memory constrained system. Debug also sometimes turns on overrun buffers so you can check for over/under runs in your code at debug time. Some compilers have this others dont.
    • deleted 6y ago
      [deleted]
• krylon 6y ago
  Yes, I think that was the main reason. It was kind if pointless, though, the biggest file I saw in my time there was around 10MB. How much bigger would that have been with padding? Even an overhead of 100% probably would not have had much of a performance impact and saving a few megabytes of disk space or RAM was not a very strong argument at the time any more (roughly 2007 - 2009) On the other hand, this was a natural outgrowth of the other programmers' tendency to keep it simple and avoid bloat, which all in all I appreciated very much.