Sunspider 0.9.1 http://www.webkit.org/perf/sunspider/sunspider.html 173.2 ms Chrome 185.8 ms Chromium Chromium was compiled with compiler and flags which should be very similar to ones used with Chrome GCC 4.4.7 www-client/chromium: -O2 -march=x86-64 -fomit-frame-pointer dev-lang/v8: -O3 -march=x86-64 -fomit-frame-pointer using different flags with v8 didn't help
Please stop it. I've said "Feel free to file a separate bug after figuring out why exactly the slowdown occurs.". This bug is just re-iterating the 7% slowdown on your system. Some possible things to try: 1. Compile chromium in "vanilla" configuration, e.g. no system libs on your system. 2. Use a more recent gcc. 3. Have a _hypothesis_ that can be validated. Do not just say it's slower and post some numbers and flags. Say why you think it's slower, post the number and flags, and also post the numbers for your suggested fix. 4. If your suggested fix is to use google-chrome, why don't you do just that? :) Benchmarks do depend on how things have been compiled, that's no news. 5. I'm still open to possible ideas for improvements (we *might* even get back to bundled v8 since both projects are closely related, and other consumers of v8 seem not to keep up with the updates - e.g. nodejs), but for that you need to suggest a change and provide performance data for the case with and without the change. *** This bug has been marked as a duplicate of bug 454542 ***
about half of difference is caused by v8 compiled with snapshot=off on hardened with system v8 compiled with snapshot=on 177.8 ms with GCC 4.7 and custom-cflags ~180 ms with GCC 4.4.7 I prefer to use web browser compiled on my machine because of various reasons.
(In reply to comment #2) > about half of difference is caused by v8 compiled with snapshot=off on > hardened > > with system v8 compiled with snapshot=on > 177.8 ms with GCC 4.7 and custom-cflags > ~180 ms with GCC 4.4.7 > > I prefer to use web browser compiled on my machine because of various > reasons. This is reasonable. I'll look into making it possible to build with snapshot=on on hardened (PaX).
(In reply to comment #3) > This is reasonable. I'll look into making it possible to build with > snapshot=on on hardened (PaX). I think we will have to pax-mark the mksnapshot program part-way through the build process to make this happen.
Created attachment 339190 [details, diff] Diff against v8-3.16.11.1 Here's an ebuild patch that should work. Please review. To summarize it: 1. Define src_configure, and move all the gyp-related logic there. 2. Call make to generate out/Makefile.${myarch} using gyp. 3. In src_compile, call make to build the mksnapshot command, and then pax-mark it. 4. Call make again to generate the snapshot file and build the rest of the binaries. I think this should be pretty reliable, unless v8 upstream makes some major change to their top-level makefile.
(In reply to comment #5) > Created attachment 339190 [details, diff] [details, diff] > Diff against v8-3.16.11.1 > > Here's an ebuild patch that should work. Please review. LGTM (Looks Good To Me). Awesome!
+ 18 Feb 2013; Mike Gilbert <floppym@gentoo.org> v8-3.16.11.1.ebuild, + v8-9999.ebuild: + Adjust build process to enable snapshot on PaX systems, bug 454720. Should we apply this for 3.15?
(In reply to comment #7) > + 18 Feb 2013; Mike Gilbert <floppym@gentoo.org> v8-3.16.11.1.ebuild, > + v8-9999.ebuild: > + Adjust build process to enable snapshot on PaX systems, bug 454720. > > Should we apply this for 3.15? Up to you. Fine for me. :)
Done. @wbrana: If you find any other ways to improve performance here, let us know.
