Repository navigation
Performance regression in 3.16.14 series? #150
Description
We upgraded libv8 to the 3.16.14 series last week and started seeing significantly slower asset compilation times (through Uglifier) compared to v3.11.8.17. I came at this through Rails' Asset Pipeline, so I'm way in the weeds here and don't know if it's libv8 or V8 itself, but thought I'd ask here to see if anyone had similar experiences.
This doesn't seem to affect times on my dev machine (OS X 10.10, Intel Core i7), but it's between 2x and 5x slower on our production servers (Scientific Linux 6.5, AMD). Seems to be worse for larger files (obviously in strict wall-clock time, but also closer to 5x+ slower on the big files).
Benchmarks for Uglifier.compile(), which is just the easiest way I know how to test:
_libv8-3.11.8.17-x86_64-linux_
Compiling bootstrap.js (62kb, not minified)
0.700000 0.030000 0.730000 ( 0.721680)
0.670000 0.030000 0.700000 ( 0.688308)
Compiling highcharts.js (496kb, not minified)
4.510000 0.040000 4.550000 ( 4.499848)
4.250000 0.030000 4.280000 ( 4.238179)
Compiling jquery-1.8.1.min.js (93kb, already minified)
2.630000 0.040000 2.670000 ( 2.639083)
2.540000 0.030000 2.570000 ( 2.548431)
Compiling jquery-ui-1.8.23.min.js (205kb, already minified)
3.320000 0.070000 3.390000 ( 3.345508)
3.360000 0.070000 3.430000 ( 3.382746)
Compiling application.js (900kb, mixed)
15.020000 0.300000 15.320000 ( 15.129480)
16.170000 0.180000 16.350000 ( 16.162925)
_libv8-3.16.14.3-x86_64-linux_
Compiling bootstrap.js (62kb, not minified)
0.980000 0.010000 0.990000 ( 0.976608)
0.860000 0.020000 0.880000 ( 0.865921)
Compiling highcharts.js (496kb, not minified)
8.720000 0.080000 8.800000 ( 8.736296)
7.230000 0.060000 7.290000 ( 7.230722)
Compiling jquery-1.8.1.min.js (93kb, already minified)
4.110000 0.080000 4.190000 ( 4.153838)
3.830000 0.030000 3.860000 ( 3.830293)
Compiling jquery-ui-1.8.23.min.js (205kb, already minified)
7.260000 0.060000 7.320000 ( 7.273115)
6.580000 0.030000 6.610000 ( 6.579161)
Compiling application.js (900kb, mixed)
82.280000 0.190000 82.470000 ( 82.314145)
87.490000 0.220000 87.710000 ( 87.526244)
Anyone experiencing anything similar, or have any ideas on what might cause this?
Activity
ledbettj commentedon Nov 12, 2014
Here are some ruby-prof traces of the two versions mentioned above, simply using Uglifier to compress a 1.4mb javascript file. 3.16.14.7 took approximately 70 seconds, while 3.11.8.17 completed in about 18.
V8::C::String#Utf8Valueseems to be the culprit at first glance.ignisf commentedon Nov 12, 2014
Very interesting. Thank you, @ledbettj.
ignisf commentedon Nov 12, 2014
Hmm... Looking at https://github.com/cowboyd/therubyracer/blob/master/ext/v8/string.cc#L22 I'm not sure the regression is caused by v8. @cowboyd needs to weigh in here.
ledbettj commentedon Nov 12, 2014
Just to make sure I include all the variables, the version of
therubyraceralso changed. Sorry for not including this in the initial post.Faster:
Uglifier 2.5.3 / libv8 3.11.8.17 / therubyracer 0.11.4Slower:
Uglifier 2.5.3 / libv8 3.16.14.7 / therubyracer 0.12.1beekermememe commentedon Feb 4, 2015
+1 on this, We are going from 5 minute deploys up to 18 minutes when deploying to C1 large instances
Rails 3.2.21. We are running a SPA so a good few JS files.
pseidemann commentedon Jul 6, 2015
+1
stefankaiser commentedon Sep 9, 2015
+1
SamSaffron commentedon May 2, 2016
I am going to have to debug this, as it stands it takes us 12 seconds to simply run our JS snippets through babel to build application.js, this feels way too long.
I completely eliminated the ruby racer from our assets minification pipeline due to this huge performance hole. Going to work on some simpler repros this week, but this issue does need more attention.
ignisf commentedon May 2, 2016
A reproduction would help. Let me know if I can help in some way. Unfortunately profiling c++ is a bit out of my league or I would have taken a crack at this.
11 remaining items
SamSaffron commentedon May 13, 2016
I was able to install fine on my osx but had to upgrade xcode to latest
first to get latest clang
On Fri, May 13, 2016 at 11:08 AM, Petko Bordjukov notifications@github.com
wrote:
ignisf commentedon May 15, 2016
For the record, here are results from running mini_racer's
benchmarks/bench_uglify.rb:Will keep this issue open for now and hopefully close it after TRR is updated as we'll have to keep around 3.16.14 support at least until then.
coding-horror commentedon May 15, 2016
Wow an exponential scale eh? :)
ignisf commentedon May 15, 2016
😞
SamSaffron commentedon May 16, 2016
This does illustrate a huge issue with exponential scale graphs :)
I would really like to rerun these numbers on Linux x64 comparing GCC vs clang compiled libv8 and mini_racer, I am very curious to see the performance difference
ignisf commentedon May 16, 2016
You should be able to do this by locking the version to the source release and configuring a compiler. One thing to note is that at least from the build guide it seems like clang is the preferred compiler for v8.
I don't expect there to be any major differences in performance just solely based on compiler choice, though as the recent versions of gcc and clang don't differ too much in their benchmark scores. What could lead to a performance boost would be enabling link-time optimisations. I have not looked into that yet, though I think there's support for this in v8's build system (for linux).
ignisf commentedon May 16, 2016
I am really not sure we should just flick on LTO :D
Alrighty, let's retry this without MAKEFLAGS=-j4 and see how much memory is required for linking...
ignisf commentedon May 16, 2016
Peak memory used for linking with lto on one make job is around 3,5512 GB. The produced binary gem archive is 275 MB.
It seems that LTO is enabled automatically when linking the mini_racer_extension.so against a LT optimised version of the libv8 static library (Linux x86_64, GCC 6.1.1).
Could not benchmark because invoking the benchmark script causes a segfault. LTO-enabled branch can be found here: https://github.com/cowboyd/libv8/tree/lto.
I don't see us turning on the lto flag by default for the source distribution (due to the memory footprint), but it could be used for the binaries if anybody can get anything linked to not segfault.
SamSaffron commentedon May 16, 2016
phoronix had some pretty mixed results with lto ..
http://www.phoronix.com/scan.php?page=article&item=gcc_471_lto&num=3
I mentioned the clang tests cause another bench I have has node clocking
20% faster so I am curious if this is the compilation of something
internal.
On Mon, May 16, 2016 at 3:19 PM, Petko Bordjukov notifications@github.com
wrote:
SamSaffron commentedon Jun 9, 2016
I think it is fine to close this for now, nothing more for libv8 to do in this regard
ignisf commentedon Jun 15, 2016
I had to add
-fltoflag for in mini_racer'sCXXFLAGSto get it to compile against LTO libv8. Binaries produced with GCC and-fltoconsistently segfault. My verdict for now is that LTO at this point is more trouble than it's worth.