Re: [webkit-dev] [Conditional=] vs. #if in IDL files

[Steven Coul (scoul)]

A rebuild from scratch with no ccache is 48m approx. So 34 seconds isn’t so 
useful.

My “normal” build case involves pulling updates from webkit.org once or twice a 
day and rebuilding WTF/JSCore/WebCore with my patch set. I also do a clean 
rebuild prior to my local commits since it’s the best way to avoid having to 
revert or fix stuff too often.

Over the last 10 weeks, these builds have averaged 6m24s. So 34 seconds there 
is more significant.

Steve "Harry" Coul
sc...@cisco.com



On Mar 10, 2015, at 11:09 AM, Darin Adler  wrote:

>> On Mar 9, 2015, at 5:02 PM, Steven Coul (scoul)  wrote:
>> 
>> The IDL processing time went from 139 seconds real time to 105.
> 
> 34 seconds sounds like substantial savings. What’s the total build time for 
> you on that computer?
> 
> — Darin



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Conditional=] vs. #if in IDL files

[Steven Coul (scoul)]

On Mar 9, 2015, at 2:52 PM, Darin Adler  wrote:

>> On Mar 9, 2015, at 5:39 AM, Steven Coul (scoul)  wrote:
>> 
>> Would [Conditional] use through out also not allow us to perform the IDL 
>> compile without running the c preprocessor on each file?
> 
> Possibly.
> 
>> Can [Conditional] not be fixed to support multiple flags?
> 
> It does support multiple flags.
> 
>> The compiling of IDL is a significant portion of the total build time, and 
>> ccache distcc et al cannot help us there.
> 
> 
> Worth doing the math to figure out how much of the time is the C preprocessor.
> 
> — Darin


I’m really out of my depth on perl - but for a quick and dirty hack,  I 
modified the preprocessor script to save the output, then copied the output 
back over a clean source tree and tweaked a few other sources that are 
generated. Then modified the preprocessor.pm script to just chomp() the new 
files instead of spawn cpp.

The IDL processing time went from 139 seconds real time to 105. So getting 
close to 1/4 the time is spent in the preprocessor for me. ( or more likely the 
forking/exec’ing of the pre processor tool ).

This is a Ubuntu VMware install on a macbook pro.

I’ve no idea how to go about doing this properly and folding it into the 
official build machine / build scripts.

Steve "Harry" Coul
sc...@cisco.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Conditional=] vs. #if in IDL files

[Steven Coul (scoul)]

Would [Conditional] use through out also not allow us to perform the IDL 
compile without running the c preprocessor on each file? 

Can [Conditional] not be fixed to support multiple flags?

The compiling of IDL is a significant portion of the total build time, and 
ccache distcc et al cannot help us there.

Steve "Harry" Coul
sc...@cisco.com



On Mar 7, 2015, at 6:47 PM, Ryosuke Niwa  wrote:

> On Sat, Mar 7, 2015 at 8:55 AM, Darin Adler  wrote:
> Why do we have [Conditional=] in our IDL files? Perhaps because some ports 
> lacked a way to do #if in the past?
> 
> I think Conditional is a nicer/newer way of if-defing based on feature flags.
>  
> Should we use #if or [Conditional]? See for example, HTMLMediaElement.idl, 
> which has a mix of both styles. It’s pretty ugly how the #if look in the IDL 
> files, but even worse is a seemingly random mix of both #if and [Conditional].
> 
> We should use Conditional as much as possible.
> 
> As far as I know one area we can't use Conditional= is if something depends 
> on multiple feature flags or if it's specific to a binding language 
> (JS/Objective-C/etc...).  We should probably add a special feature flag for 
> that; e.g. Conditional=JS.
> 
> - R. Niwa
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency

[Steven Coul (scoul)]

Naive question(s) here.

Why does the physical number of cores ( and that is not necessarily the number 
of actionable native threads ) matter?

I would expect a mature system to do the best it can with hardware, in what the 
software has asked for it. Some tasks are sleepy, some are IO bound, some CPU - 
this is the job of the host kernel to cope.

Whilst I can accept that there are some tasks for which you  may want to craft 
your number of workers for to get the best CPU/GPU through put - this sounds to 
be to be in the realm of something for which you probably shouldn’t be coding 
in javascript inside a web browser for.

( I’m also not immune to concern about security re: fingerprinting - but then, 
how much information do you really get from that? Given the propensity to use 
virtual machines / cloud - the number of “processors” is pretty mutable ).

Personally, I like to control CPU usage - I’m happy restricting my browser to 2 
cores - so the others are free for other tasks as a developer - you can’t ask 
an uninformed user to handle cpu binding - so relying on the host OS to “do the 
best it can” and assuming you have say 1..4 “cores” in an app should work.

Anything else is high-performance computing. I’m not convinced that a 
web-browser is the place to worry about that.

I’m also leary of anything not standards based - so perhaps *somebody* should 
push for a standard whereby you can ask the host os ‘ how many threads can you 
handle right now?” - which may or may not be number of cores - depending on 
system load.

Steve "Harry" Coul
sc...@cisco.com



On May 7, 2014, at 7:38 PM, Rik Cabanier 
mailto:caban...@gmail.com>> wrote:




On Wed, May 7, 2014 at 5:07 PM, Benjamin Poulain 
mailto:benja...@webkit.org>> wrote:
On 5/7/14, 4:13 PM, Benjamin Poulain wrote:
On 5/7/14, 3:52 PM, Filip Pizlo wrote:
Exactly. Ben, Oliver, and others have made arguments against web
workers. Rik is not proposing web workers.  We already support them. The
point is to give API to let developers opt into behaving nicely if they
are already using web workers.

I have nothing against Web Workers. They are useful to dispatch
background tasks.

They are basically the Web equivalent dispatch_async() of GCD, which is
already a very useful tool.

What you are suggesting is useful for making Web Workers the tool to do
high performance multi-thread computation.
I don't think Web Workers are a great tool for that job at the moment. I
would prefer something along TBB, GCD or something like that.


For high performance computation, I think a more useful API would be
something like TBB parallel_for with automatic chunking.
It is actually had to do faster than that with the number of cores
unless you know your task very very well.

It would be a little more work for us, but a huge convenience for the
users of Web Workers.

After chatting with Filip, it seems such a model is unlikely to happen anytime 
soon for JavaScript.

In the absence of any tasks/kernels model, I am in favor of exposing a "good 
number of thread" API. It is definitely better than nothing.

Do we know what this number would be? My guess would be the number of cores for 
"regular" systems...
Boris Zbarsky indicated that Firefox figures out how many workers should run 
concurrently. Maybe we can reuse that algorithm?

They can already write code that overloads the system but they currently
have *no* way of writing code that even tries to be well-behaved except
maybe to avoid workers entirely.

I'm also a little disturbed by arguments against the general usefulness
of ncpu. We use it for the parallel JIT and parallel GC because
regardless of system load those are *the best* guesses of how many cpus
to use.

-Fil

On May 7, 2014, at 3:24 PM, Rik Cabanier 
mailto:caban...@gmail.com>
>> wrote:




On Wed, May 7, 2014 at 3:19 PM, Oliver Hunt 
mailto:oli...@apple.com>
>> wrote:


On May 7, 2014, at 3:15 PM, Rik Cabanier 
mailto:caban...@gmail.com>
>> wrote:




On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt 
mailto:oli...@apple.com>
>> wrote:


On May 7, 2014, at 2:41 PM, Rik Cabanier 
mailto:caban...@gmail.com>
>> wrote:
>
> When would I as a user, not want a page or web application
to be as fast as possible? Has a user ever complained about a
desktop app that uses too many of his CPU's? I think Oliver's
point was that other processes might fight for the same CPU
resources but that is not unexpected for users.

What happen if i go to your website while i'm doing something
else in the background?  What if i'm playing a game while
waiting for my machine to do something else? What if your
p

Re: [webkit-dev] Moving ChangeLog-date files into their own subdirectory?

[Steven Coul (scoul)]

Okay, 

But then, information in the change logs is also mirrored in the repo log. For 
instance, could you not do “git log | grep ” ?

There have been great pains in the past to keep the tree “pure” on the basis 
that old stuff you might need can be pulled from the repo - is this not just an 
extension of that?

It strikes me that keeping the logs in this manner is either a limitation in 
the repo tools, or just a workflow habit that can be changed.


As you allude to, it’s your workflow that requires these files. In that case, 
could not your workflow simply access the repo history in “some-other-manner” ?

If we are not going to keep functional but currently unused code visible, why 
bother with ancient-history ?

Just seems a bit inconsistent.

( TBH, I actually don’t care that much, expect when in my own workflow i search 
for something - and keep forgetting to tell my command line to ignore 
ChangeLog* ;-) )


Steve "Harry" Coul
sc...@cisco.com



On May 7, 2014, at 8:05 PM, Darin Adler  wrote:

> 
> On May 7, 2014, at 3:51 PM, Steven Coul (scoul)  wrote:
> 
>> Or just remove them?
> 
> I grep them all the time. I don’t think removing them would be a good thing.
> 
> Many projects use the configuration management system’s own change logging 
> system rather than an explicit text file, but that’s not how we’ve been doing 
> things in WebKit.
> 
> — Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Moving ChangeLog-date files into their own subdirectory?

[Steven Coul (scoul)]

Or just remove them? They’ll be available in the repo anyhow.


Steve "Harry" Coul
sc...@cisco.com



On May 7, 2014, at 4:20 PM, Zoltan Horvath  wrote:

> Hi there,
> 
> We're having more and more 'archived' change log files in our tree. Can't me 
> move/archive these files into their own subdirectory?
> 
> Motivation: Showing less files on a directory listing.
> 
> e.g.
> LayoutTests/ChangleLog-2014-02-20 would be moved under 
> LayoutTests/ChangeLog-archive/ subdirectory in the future, and so on.
> 
> What do you guys think?
> 
> Cheers,
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is anyone using the LevelDB backend to IndexedDB?

[Steven Coul (scoul)]

Is there an alternative to levelDB without going to webkit2 ?

Steve "Harry" Coul
sc...@cisco.com



On Apr 28, 2014, at 4:20 AM, ryuan Choi 
mailto:ryuan.c...@webkit.org>> wrote:

WebKit/Efl dropped level db dependency (and disabled leveldb)


2014-04-28 16:44 GMT+09:00 Raphael Kubo da Costa 
mailto:rak...@webkit.org>>:
Darin Adler mailto:da...@apple.com>> writes:

> On Apr 25, 2014, at 1:05 AM, Raphael Kubo da Costa 
> mailto:rak...@webkit.org>> wrote:
>
>> Sam Weinig mailto:wei...@apple.com>> writes:
>>
>>> Hello,
>>>
>>> Is anyone using the LevelDB backend to IndexedDB?
>>
>> The EFL and GTK+ ports are.
>
> Are you sure?
>
> Since the GTK+ port is now WebKit2-only, then it can’t be using the
> LevelDB back end at this time, because I believe nobody has made it
> work in WebKit2 yet.

Right, so it's only the build system that sets WTF_USE_LEVELDB to 1 and
builds the LevelDB stuff in ThirdParty.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebGL backends

[Steven Coul (scoul)]

Would this be simplify as in tidy up existing code, get down to a simple subset 
of required functionality, and maybe abstracting the (E)GL part?

Or are you considering a simplification by just saying it will be EGL version 
X, and OpenGL version Y from now on and nothing else?


Steve "Harry" Coul
sc...@cisco.com



On Feb 9, 2014, at 2:59 PM, Dean Jackson  wrote:

> Hi floks.
> 
> I’m looking into simplifying our WebGL code, particularly our 
> GraphicsContext3D implementations. Apple uses either the OS X or iOS OpenGL 
> backend for its ports, but it isn’t clear to me what backend the other ports 
> are using.
> 
> Could the other port developers please reply to let me know how you’re 
> accessing OpenGL?
> 
> Thanks,
> 
> Dean
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Remove ENABLE(SVG)

[Steven Coul (scoul)]

My big worry about that, is that somewhere somebody is thinking about using 
that argument to add Flash and/or Moonlight to Webkit - and down that path 
madness lies ;-)

There really aren’t any “size-hogs” in WK other than SVG itself - but it’s been 
a while since I looked I admit.

I tend to think of “fork it” as a last desperate measure rather than first plan 
- but whatever - I was just interested in others opinions since I don’t have a 
horse in this race anyhow.

Steve "Harry" Coul
sc...@cisco.com



On Feb 4, 2014, at 8:52 AM, Dirk Schulze  wrote:

> 
> On Feb 4, 2014, at 5:20 AM, Steven Coul (scoul)  wrote:
> 
>> I agree, the time taken to build is not really a good reason for the change 
>> or lack of - as you point out there, are many other ways to optimize the 
>> build process/server which will have wider benefits.
>> 
>> But does anybody consider size to be an issue? SVG adds a fair chunk to the 
>> size of a binary - especially in debug builds - which is not very friendly 
>> to embedded systems.
>> 
>> ( Real embedded, not just a small form factor $500 PC running Windows etc )
>> 
>> I know in general WK seems to be aimed at desktop, big mobile etc - and we 
>> tend to ignore anything not directly related to the the main builds, but 
>> even on a desktop I wouldn’t mind seeing a crusade to make things smaller. 
>> One day I’ll see my whole OS in L1 Cache……..
> 
> In this case you may want to branch WebKit and remove more than just SVG.
> 
> WebKit is a browser engine and should display web content. There is no doubt 
> anymore that SVG is an integral part of the web. That is the the only 
> decision that matters here IMO.
> 
> Greetings,
> Dirk
> 
>> 
>> Steve "Harry" Coul
>> sc...@cisco.com
>> 
>> 
>> 
>> On Feb 4, 2014, at 6:11 AM, Osztrogonác Csaba  wrote:
>> 
>>> Xabier Rodríguez Calvar írta:
>>>> Sorry for the late answer, but I was in Brussels at FOSDEM.
>>>> O Ven, 31-01-2014 ás 14:01 +0100, Alberto Garcia escribiu:
>>>>> Not in the GTK+ port at least, I've been able to do builds without
>>>>> SVG perfectly fine, so there's probably something else wrong in your
>>>>> environment or the port you're using.
>>>>> 
>>>>> Anyway, I'm also fine with removing it.
>>>> It saves some times in our builds and I always use it unless I have to
>>>> do something with SVG.
>>>> I would keep it unless it doesn't pay off the effort of maintaining it.
>>>> Br.
>>> 
>>> I've checked the full clean build time of GTK port on a quad core i5-2320 
>>> (3GHz) machine with icecc buildfarm and -j30 makeflag:
>>> - with SVG disabled:"WebKit is now built (11m:58s)."
>>> - with SVG enabled: "WebKit is now built (13m:38s)."
>>> 
>>> The difference isn't so big. But it was clean build, I don't think if
>>> developers always do clean builds. If you don't touch SVG related files,
>>> the build time shouldn't depend on enabled/disabled SVG.
>>> 
>>> In my opinion the ENABLE(SVG) flag is not to speed up clean builds, but
>>> disable SVG if you don't want to ship it. There are so many way to speed
>>> up builds:
>>> - use more cores, use icecc buildfarm, use ccache
>>> - get rid of include paths and use module relative includes
>>> (But it can be a separated thread if anybody is interested in it.)
>>> 
>>> Ossy
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Remove ENABLE(SVG)

[Steven Coul (scoul)]

I agree, the time taken to build is not really a good reason for the change or 
lack of - as you point out there, are many other ways to optimize the build 
process/server which will have wider benefits.

But does anybody consider size to be an issue? SVG adds a fair chunk to the 
size of a binary - especially in debug builds - which is not very friendly to 
embedded systems.

( Real embedded, not just a small form factor $500 PC running Windows etc )

I know in general WK seems to be aimed at desktop, big mobile etc - and we tend 
to ignore anything not directly related to the the main builds, but even on a 
desktop I wouldn’t mind seeing a crusade to make things smaller. One day I’ll 
see my whole OS in L1 Cache……..

Steve "Harry" Coul
sc...@cisco.com



On Feb 4, 2014, at 6:11 AM, Osztrogonác Csaba  wrote:

> Xabier Rodríguez Calvar írta:
>> Sorry for the late answer, but I was in Brussels at FOSDEM.
>> O Ven, 31-01-2014 ás 14:01 +0100, Alberto Garcia escribiu:
>>> Not in the GTK+ port at least, I've been able to do builds without
>>> SVG perfectly fine, so there's probably something else wrong in your
>>> environment or the port you're using.
>>> 
>>> Anyway, I'm also fine with removing it.
>> It saves some times in our builds and I always use it unless I have to
>> do something with SVG.
>> I would keep it unless it doesn't pay off the effort of maintaining it.
>> Br.
> 
> I've checked the full clean build time of GTK port on a quad core i5-2320 
> (3GHz) machine with icecc buildfarm and -j30 makeflag:
> - with SVG disabled:"WebKit is now built (11m:58s)."
> - with SVG enabled: "WebKit is now built (13m:38s)."
> 
> The difference isn't so big. But it was clean build, I don't think if
> developers always do clean builds. If you don't touch SVG related files,
> the build time shouldn't depend on enabled/disabled SVG.
> 
> In my opinion the ENABLE(SVG) flag is not to speed up clean builds, but
> disable SVG if you don't want to ship it. There are so many way to speed
> up builds:
> - use more cores, use icecc buildfarm, use ccache
> - get rid of include paths and use module relative includes
>   (But it can be a separated thread if anybody is interested in it.)
> 
> Ossy
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] C stack direction

[Steven Coul (scoul)]

If it was code in JavaScriptCore that was no longer used I could see the point,

But since it's WTF functionality that isn't being used in another component 
atm. I would tend to keep it. 

But then I've always hated ( and been bitten by ) things like "its allways 
going to be 32bit, chars are always signed, stacks always grow down,  
everything is little-endian" etc. So maybe I'm over-protective. 

Just my 2c.

Thanks.

-Original Message-
From: webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Mark Lam
Sent: Wednesday, November 20, 2013 2:25 PM
To: webkit-dev@lists.webkit.org Development
Subject: [webkit-dev] C stack direction

Hi folks,

I'm currently doing some work involving checks on the bounds of the native 
stack.  According to WTF::StackBounds, it appears that WINCE is the only port 
that can potentially have a stack that grows up.  Is anyone still building, 
testing, and using this configuration with an upward growing stack?  I'm 
wondering whether to drop support for upward growing stacks altogether.  Our 
JITs already don't support it.  Any opinions?

Thanks.

Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev