Optimization for reading *.d files

2017-03-18 Thread brenorg
Hi everybody, I'm currently refactoring the build system at my company. We got around 20k C++ source files, and we use a form of (messed up) recursive make. After a lot of tinkering to get things right I got to 10 (maybe 5 with some more massage) seconds for a clean build. I need something around

Re: Optimization for reading *.d files

2017-03-18 Thread brenorg
performance testing with a version of make > that old. You are right. I'll do that and get back with the results. Paul Smith-20 wrote > On Sat, 2017-03-18 at 19:25 -0700, brenorg wrote: >> There are lots of dependency files and they can be processed in parallel, >> before

Re: Optimization for reading *.d files

2017-03-19 Thread brenorg
Hi Norbert, You are absolutely right. There is much more redundancy than I expected. I joined all .d files in one single file and after running make on it and printing the database, it's actually 10x smaller. And I know there must be more duplication since my files names are not all relative to th

Re: Optimization for reading *.d files

2017-03-19 Thread brenorg
Wow! I appreciate it :) -- View this message in context: http://gnu-make.2324884.n4.nabble.com/Optimization-for-reading-d-files-tp17656p17663.html Sent from the Gnu - Make - Bugs mailing list archive at Nabble.com. ___ Bug-make mailing list Bug-make@

Re: Optimization for reading *.d files

2017-03-19 Thread brenorg
Paul Smith-20 wrote > On Sat, 2017-03-18 at 22:49 -0700, brenorg wrote: >> > I'd prefer to investigate improving the existing parser, rather than >> > create a completely separate parser path. >> >> I could agree if the difference were 10x or more. But