Re: Optimization for reading *.d files

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 I believe 2x a >> reasonable gain from

Re: Optimization for reading *.d files

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

Re: Optimization for reading *.d files

On Sun, Mar 19, 2017 at 11:54 AM, brenorg wrote: > 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

Re: Optimization for reading *.d files

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 I believe 2x a > reasonable gain from removing so many features. From

Re: Optimization for reading *.d files

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

Re: Optimization for reading *.d files

On Sat, Mar 18, 2017 at 9:25 PM, brenorg wrote: > > Anyway, I want to continue to use GNU Make, and not fallback to CMake/Ninja. > After some profiling, what's killing me is parsing the "*.d" files generated > by the compiler. > > The time to include all dependency files of my