> > 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*
_______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
