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
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
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
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
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
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