Sorry to open up this discussion again, :) Based on the recent developments
in bug https://bugs.webkit.org/show_bug.cgi?id=32452 and
https://bugs.webkit.org/show_bug.cgi?id=69469, it seems like some are keen
on having V8 as an configurable build option in WebKit-GTK.
One obvious advantage of using V8 in WebKit-GTK is faster JS engine (at this
point of time!). Moreover, it will be provided as separate build option and
SFX will continue to be the default JS engine. If we ever in future wish to
shift completely to V8, such transition would be smoother.
On the down-side, I understand the concern about code maintainability and we
are ready to maintain any code changes that are added for V8.
Please let me know your suggestions, concerns, comments and feedback, we
will try to address them and conclude on whether to push this patch or not.
Thanks,
On Wed, Sep 7, 2011 at 7:48 PM, Nayan Kumar K naya...@motorola.com wrote:
As promised earlier, here is the blog post with the performance results of
V8 and JSC on an embedded target
http://xc0ffee.wordpress.com/2011/09/07/webkit-gtk-jsc-vs-v8-performance-on-arm/.
These
results seem to favor V8, both in x86-64 bit machine and in an ARM target.
Given this, please let us know your opinions in pushing these changes to
webkit. Based on it, I will start re-factoring the patch to ease
code-maintainability and code review.
Thanks,
On Sun, Aug 28, 2011 at 1:22 AM, Nayan Kumar K naya...@motorola.comwrote:
Here is the performance analysis between JSC and V8 on an x86 reference
machine - http://xc0ffee.wordpress.com/2011/08/27/webkit-gtk-jsc-vs-v8/.
I am also planning to benchmark the results on an arm reference board,
will publish the results soon.
On Wed, Aug 3, 2011 at 10:53 PM, Nayan Kumar K naya...@motorola.comwrote:
We have discussed about this in the past, the conclusion was that
adding all this code without a good reason is not that interesting,
our understanding is that in big projects with long story you have to
care about the code maintainability not just adding features. It will
add more work to maintain the port and more complexity when trying to
do some things. And basically performance tests were showing we have
both
engines in the same ballpark so choosing one or the other will not
give any benefit to the user.
I agree about your concerns on code maintainability. Please note that the
patch was uploaded just for feedbacks/questions/concerns (like this. :)). I
believe that this patch can be further re-factored (especially the code in
WeCore/GNUmakefile.am and WebCore/GNUmakefile.list.am files) so that it
eases the code maintenance (which I am willing to do anyways). We could aim
to push this patch with at-most isolation as possible.
Anyway if you want to push this patch I would say the best option is
that you try to show how this is a big improvement or that it will be a
separate part of the code that will not cause any issue. But this is
just my understanding of what was the situation.
Below are the result based on a quick performance benchmarking, with
91387 of WebKit and 8745 revision of V8
Benchmarking Suite : V8 benchmark suite by Google
URL : http://v8.googlecode.com/svn/data/benchmarks/v6/run.html
Host machine: x86-64
Score with SFX: 3454
Score with V8: 8366
Of-course, judgment on performance benefit cannot be based only on V8
bench-marking suite. I will provide the results with Sunspider and Dromaeo
suite soon.
Btw, usually in this kind of patches the best idea before starting to
work is asking to the people that was already checking it why it was
stopped.
Hope it helps.
--
Cheers,
*Nayan*
--
Cheers,
*Nayan*
--
Cheers,
*Nayan*
--
Cheers,
*Nayan*
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
