Hi WebKittens,
As you might be aware, we at Opera now have Chromium based products which
means that we compile WebKit quite a lot. A big issue for us and our
automatic systems has been the long time needed to compile WebKit (inside
Chromium), especially in Windows.
The big compilation tim
On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell wrote:
> Is this something that has been talked about in the past, and would you be
> interested in replacing the long list of directories to search for every
> include with paths (relative some good base) directly in the include
> directives?
>
U
On Tue, Mar 26, 2013 at 2:37 PM, Ryosuke Niwa wrote:
> On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell wrote:
>
>> Is this something that has been talked about in the past, and would you
>> be interested in replacing the long list of directories to search for every
>> include with paths (relativ
On Tue, Mar 26, 2013 at 11:42 AM, Jarred Nicholls wrote:
> On Tue, Mar 26, 2013 at 2:37 PM, Ryosuke Niwa wrote:
>
>> On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell wrote:
>>
>>> Is this something that has been talked about in the past, and would you
>>> be interested in replacing the long list
> In WebKit include directives are without path, and instead the compiler is
> given a very long list of directories to search through. That process takes a
> lot of time in Windows. It must take some time in OSX and in Linux too but
> probably less.
Can we make a first-order improvement just b
On Tue, Mar 26, 2013 at 11:47 AM, Ryosuke Niwa wrote:
> On Tue, Mar 26, 2013 at 11:42 AM, Jarred Nicholls wrote:
>
>> On Tue, Mar 26, 2013 at 2:37 PM, Ryosuke Niwa wrote:
>>
>>> On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell wrote:
>>>
Is this something that has been talked about in the p
On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke 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
On Tue, Mar 26, 2013 at 11:37 AM, Ryosuke Niwa wrote:
> On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell wrote:
>
>> Is this something that has been talked about in the past, and would you
>> be interested in replacing the long list of directories to search for every
>> include with paths (relati
On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain wrote:
> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke 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. ha
On Tue, Mar 26, 2013 at 5:40 PM, Dirk Pranke wrote:
> On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain
> wrote:
>>
>> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke wrote
>>>
>>> If we have consensus that we should just switch to paths relative to
>>> Source (or maybe a couple different options),
On Tue, Mar 26, 2013 at 1:42 PM, Alexis Menard wrote:
> On Tue, Mar 26, 2013 at 5:40 PM, Dirk Pranke wrote:
> > On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain
> > wrote:
> >>
> >> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke
> wrote
> >>>
> >>> If we have consensus that we should just switc
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
#i
On Tuesday, March 26, 2013 01:40:56 PM Dirk Pranke wrote:
> On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain
wrote:
> > On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke wrote
> >
> >> If we have consensus that we should just switch to paths relative to
> >> Source (or maybe a couple different optio
On Mar 26, 2013, at 1:40 PM, Dirk Pranke wrote:
> On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain wrote:
> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke wrote
> If we have consensus that we should just switch to paths relative to Source
> (or maybe a couple different options), that would be
On Tuesday, March 26, 2013 01:47:26 PM James Robinson wrote:
> 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 th
+1. I also like that this will make layering violations clearer.
On Tue, Mar 26, 2013 at 1:53 PM, Filip Pizlo wrote:
>
> On Mar 26, 2013, at 1:40 PM, Dirk Pranke wrote:
>
> On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain
> wrote:
>
>> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke wrote
>>
>
On Tue, Mar 26, 2013 at 1:53 PM, Filip Pizlo wrote:
>
> On Mar 26, 2013, at 1:40 PM, Dirk Pranke wrote:
>
> On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain
> wrote:
>
>> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke wrote
>>
>>> If we have consensus that we should just switch to paths relativ
2013/3/26 Ryosuke Niwa :
> On Tue, Mar 26, 2013 at 1:53 PM, Filip Pizlo wrote:
>>
>>
>> On Mar 26, 2013, at 1:40 PM, Dirk Pranke wrote:
>>
>> On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain
>> wrote:
>>>
>>> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke wrote
If we have consensus tha
On 2013-03-26, at 11:37, Ryosuke Niwa wrote:
> On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell wrote:
> Is this something that has been talked about in the past, and would you be
> interested in replacing the long list of directories to search for every
> include with paths (relative some go
On Tue, Mar 26, 2013 at 5:17 PM, Jesus Sanchez-Palencia wrote:
> 2013/3/26 Ryosuke Niwa :
> > On Tue, Mar 26, 2013 at 1:53 PM, Filip Pizlo wrote:
> >>
> >>
> >> On Mar 26, 2013, at 1:40 PM, Dirk Pranke wrote:
> >>
> >> On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain
> >> wrote:
> >>>
> >>> On
On Mar 26, 2013, at 2:34 PM, Jarred Nicholls wrote:
> On Tue, Mar 26, 2013 at 5:17 PM, Jesus Sanchez-Palencia
> wrote:
> 2013/3/26 Ryosuke Niwa :
> > On Tue, Mar 26, 2013 at 1:53 PM, Filip Pizlo wrote:
> >>
> >>
> >> On Mar 26, 2013, at 1:40 PM, Dirk Pranke wrote:
> >>
> >> On Tue, Mar 26, 2
Den 2013-03-26 21:29:32 skrev Benjamin Poulain :
On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke 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 t
Den 2013-03-26 21:20:10 skrev Dirk Pranke :
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.
Not the whole conversion, no. J
On Tue, Mar 26, 2013 at 4:35 PM, Daniel Bratell wrote:
> Den 2013-03-26 21:29:32 skrev Benjamin Poulain :
>
>
> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke wrote
>>
>>>
>>> If we have consensus that we should just switch to paths relative to
>>> Source (or maybe a couple different options), th
On Tue, Mar 26, 2013 at 1:31 PM, Ryosuke Niwa wrote:
> Another idea. What you copied all headers into one directory (in a pre
> compilation step) and used that as the single include directory?
I don't dare chime in about full paths versus short paths, but I'd
like to point out that many ports al
On Tue, Mar 26, 2013 at 4:35 PM, Daniel Bratell wrote:
> Den 2013-03-26 21:29:32 skrev Benjamin Poulain :
>
>> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke wrote
>>
>>>
>>> If we have consensus that we should just switch to paths relative to
>>> Source (or maybe a couple different options), that
On Tue, Mar 26, 2013 at 4:51 PM, Daniel Bratell wrote:
> Den 2013-03-26 21:20:10 skrev Dirk Pranke :
>
>
> 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 a
On Mar 26, 2013, at 5:51 PM, Benjamin Poulain wrote:
> On Tue, Mar 26, 2013 at 4:35 PM, Daniel Bratell wrote:
> Den 2013-03-26 21:29:32 skrev Benjamin Poulain :
> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke wrote
>
> If we have consensus that we should just switch to paths relative to
> Sour
Den 2013-03-27 02:11:45 skrev Nico Weber :
On Tue, Mar 26, 2013 at 4:51 PM, Daniel Bratell
wrote:
Den 2013-03-26 21:20:10 skrev Dirk Pranke :
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.
Hi Daniel,
On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell wrote:
> As an experiment we took the (chromium) project webcore_dom, that normally
> compiles in 56 seconds in Windows on a generic computer and "fixed" it.
> Removing the many include paths in the build system and instead specifying
>
On Wed, Mar 27, 2013 at 12:05 PM, Brent Fulgham wrote:
> Hi Daniel,
>
> On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell wrote:
>
>> As an experiment we took the (chromium) project webcore_dom, that
>> normally compiles in 56 seconds in Windows on a generic computer and
>> "fixed" it. Removing th
Hello,
This thread already contains about 30 speculative messages. What about
providing a patch for the whole WebKit and some benchmarks on the main
platforms and compilers?
On Tue, Mar 26, 2013 at 7:21 PM, Daniel Bratell wrote:
> Hi WebKittens,
>
> As you might be aware, we at Opera now have
On Mar 27, 2013, at 12:40 PM, Pau Garcia i Quiles wrote:
> Hello,
>
> This thread already contains about 30 speculative messages. What about
> providing a patch for the whole WebKit and some benchmarks on the main
> platforms and compilers?
Good idea, want to write such a patch and put it up
On Wed, Mar 27, 2013 at 8:50 PM, Filip Pizlo wrote:
>
> On Mar 27, 2013, at 12:40 PM, Pau Garcia i Quiles
> wrote:
>
> Hello,
>
> This thread already contains about 30 speculative messages. What about
> providing a patch for the whole WebKit and some benchmarks on the main
> platforms and compil
Den 2013-03-27 20:05:03 skrev Brent Fulgham :
Hi Daniel,
On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell
wrote:
As an experiment we took the (chromium) project webcore_dom, that
normally
compiles in 56 seconds in Windows on a generic computer and "fixed" it.
Removing the many include p
Den 2013-03-27 20:40:19 skrev Pau Garcia i Quiles :
Hello,
This thread already contains about 30 speculative messages. What about
providing a patch for the whole WebKit and some benchmarks on the main
platforms and compilers?
Easier said than done.
But for sure we will keep looking at this i
On Tue, Mar 26, 2013 at 5:51 PM, Benjamin Poulain wrote:
> Hackabilty is a project goal. Compile time is not.
>
Well, in fairness, I think anyone contributing seriously to a codebase will
get more hacking done if they're spending significantly less time
recompiling :).
I happen to be someone who
Den 2013-03-26 19:21:32 skrev Daniel Bratell :
As an experiment we took the (chromium) project webcore_dom, that
normally compiles in 56 seconds in Windows on a generic computer and
"fixed" it. Removing the many include paths in the build system and
instead specifying the path in the includ
Den 2013-03-28 18:53:48 skrev Daniel Bratell :
On a Xeon W3550 (quad 3.06GHz), with plenty of RAM but a spinning disk
and Windows 7:
webcore_dom: 58 seconds -> 38 seconds (-35%)
webcore_rendering: 106 seconds -> 73 seconds (-30%)
webcore_platform: 59 seconds -> 34 seconds (-43%)
(Yes, better
Hi Daniel,
I'm afraid I don't quite understand the nature of the change you are
proposing:
1. Is it sufficient to supply the full path to the include files (e.g.,
change "Foo.h" to "WebCore/html/Foo.h") to achieve these gains?
2. ... or ... is it sufficient to copy all header files to a common in
On Tue, Apr 16, 2013 at 3:58 PM, Brent Fulgham wrote:
> Hi Daniel,
>
> I'm afraid I don't quite understand the nature of the change you are
> proposing:
>
> 1. Is it sufficient to supply the full path to the include files (e.g.,
> change "Foo.h" to "WebCore/html/Foo.h") to achieve these gains?
>
41 matches
Mail list logo
