Hi, On 31.01.19 16:01, John Beard wrote:
> I'm not really sure. I suppose it depends on the benefits it brings (and > in future with shared common libs, perhaps it won't matter as much?) I doubt it makes much of a difference — the biggest hot spots in compile time are: - waiting for pcbnew_wrap.cxx to be generated before we even start compiling pcbnew objects - cmake's dependency handling, which uses a separate dependency scan rather than generating them on the fly like automake does - compiling pcbnew_wrap.cxx (this is started fairly late, and takes the longest) - linking pcbnew three times in parallel - linking common/pcbcommon statically because of incompatible base units We could probably shave off a few seconds here or there by minimizing includes or using abstract interfaces, but that is probably not worth pursuing on its own, but might be interesting as part of unit tests. TBH, I'm not even sure the kiface mechanism really buys us anything but the option to start individual modules from the command line. I'd expect a separate 3d-viewer to contain another copy of common/pcbcommon, so it'd slow down linking and use more memory. The biggest savings we could probably get from unified units. I'd think 64 bit nanometers would be the way to go, even if that will write a lot of leading zeroes to memory, saving the extra code copies will definitely offset that. Simon
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
