[webkit-dev] Compiling WebKit up to 25% faster in Windows?

James Robinson jamesr at google.com
Tue Mar 26 13:47:26 PDT 2013


Also keep in mind that currently different build systems hack the include
path up to have the same #include point to different headers depending on
the build configuration, so the path expansion for a given #include will
not be the same for all ports.  It's basically a very non-obvious way to do
#if PLATFORM() guards at include sites without looking like it.  For
instance there are 7 different versions of AuthenticationChallenge.h but
only one #include statement in ResourceLoader.cpp.

Consider:

$ find Source/WebCore -name "*.h" -printf "%f\n" | wc -l
3383

$ find Source/WebCore -name "*.h" -printf "%f\n" | sort | uniq | wc -l
3288


- James


On Tue, Mar 26, 2013 at 1:40 PM, Dirk Pranke <dpranke at chromium.org> wrote:

> On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain <benjamin at webkit.org>wrote:
>
>> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke <dpranke at chromium.org> wrote
>>
>>> If we have consensus that we should just switch to paths relative to
>>> Source (or maybe a couple different options), that would be (IMO) a big
>>> win. It sounds like Daniel & co. have already done the big bang conversion.
>>>
>>
>> I think using full path would be a serious hit regarding hackability.
>>
>> I would rather spend some time tweaking my compiler to cache each
>> directory content than waste time finding where is every single header I
>> need to include.
>>
>>
> Interesting. I have the exact opposite experience, having to paw around to
> figure out where "Font.h" actually lives rather than just seeing
> "WebCore/platform/graphics/Font.h".
>
> At any rate, to be clear, I would be in favor of that change but I'm not
> expecting it to happen :).
>
> -- Dirk
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130326/ac06494e/attachment.html>


More information about the webkit-dev mailing list