Stacktrace performance

55 views
Skip to first unread message

Wilfried Gösgens

unread,
Feb 10, 2020, 10:20:51 AM2/10/20
to v8-users
Hi,
reading the changelog I saw that many things changed about stacktrace generation in the recent V8 versions, which should change the performance of generating the error instance?
I've tried this simple test with arangodb's arangosh and its embedded V8 versions 7.1 and 7.9:

function test1() {
 
function test2() {
   
function test3() {
     
function test4() {
       
function test5() {
         
function test6() {
           
function test7() {
             
function test8() {
                x
= new Error;
               
return 1;
             
}
             
return test8();
           
}
           
return test7();
         
}
         
return test6();
       
}
       
return test5();
     
}
     
return test4();
   
}
   
return test3();
 
}
 
return test2();
}

before
= time();
for (let i = 1; i < 50; i ++) {
  test1
();
}
print(time() - before);


7.1:  - (as in ArangoDB 3.6) 0.0012750625610351562
7.9: - (as in current devel) 0.6016845703125

The figures are similar when I throw the error and catch it inside that for loop.
I've read that later V8 reparses the source in order to get the printeable stacktrace; is this what gives such a worse performance here?
If yes, which way is one to achieve similar / faster performance with recent V8 versions?

Cheers,
Willi

Dan Elphick

unread,
Feb 10, 2020, 11:03:29 AM2/10/20
to v8-u...@googlegroups.com
It sounds like you're talking about lazy source positions, but the code you've listed there shouldn't be affected by that since it never symbolizes a stack trace. You could confirm that by disabling it with the flag --no-enable-lazy-source-positions.

If you added "var a = x.stack;" to your test8 function then it would trigger symbolization (without printing it), since stack is actually a function masquerading as a variable and so even accessing it will trigger source position collection. I would then expect the first iteration to be slower as it reparses, but then subsequent iterations would be fast.

Dan

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/f27ad537-86c5-4f3e-be8c-b25b73dea7af%40googlegroups.com.
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted

Wilfried Gösgens

unread,
Feb 12, 2020, 7:28:09 AM2/12/20
to v8-users
Hi, 
for the json tests the results are looking really promising (its this ~2MB sized file: https://github.com/arangodb/arangodb/tree/devel/js/apps/system/_admin/aardvark/APP )

However, all the throw tests don't look as good. `--no-enable-lazy-source-positions` doesn't bring me in the range of the older V8; am I missing something about my tiny test program?

Arangodb 3.6.1:  (V8 7.1)
docker -v /tmp/:/tmp/ run -it arangodb:3.6.1 /bin/sh

cd
/usr/share/arangodb3; /usr/bin/arangosh --javascript.execute /tmp/test.js JSON parse:     11.244979858398438
stack frames A
: 0.0011951923370361328
stack frames B
: 0.0011119842529296875
stack frames c
: 0.0015842914581298828
stack frames c
: 0.0014750957489013672
stack frames d
: 0.0006735324859619141

stack frames d
: 0.0005927085876464844


devel: (V8 7.9)
docker run -v /tmp/:/tmp/ -it arangodb/arangodb-preview:devel-nightly /bin/sh

cd
/usr/share/arangodb3; /usr/bin/arangosh '--javascript.v8-options=--enable-lazy-source-positions' --javascript.execute /tmp/test.js



JSON parse
:     4.552847385406494
stack frames A
: 0.001809835433959961
stack frames B
: 0.0014481544494628906
stack frames c
: 0.0021665096282958984
stack frames c
: 0.002079486846923828
stack frames d
: 0.0009906291961669922
stack frames d
: 0.001043081283569336



cd /usr/share/arangodb3; /usr/bin/arangosh '--javascript.v8-options=--no-enable-lazy-source-positions' --javascript.execute /tmp/test.js


JSON parse
:     4.576668739318848
stack frames A
: 0.0018227100372314453
stack frames B
: 0.0014328956604003906
stack frames c
: 0.0021677017211914062
stack frames c
: 0.002074718475341797
stack frames d
: 0.0009608268737792969
stack frames d
: 0.0008444786071777344



cheers,
Willi
To unsubscribe from this group and stop receiving emails from it, send an email to v8-u...@googlegroups.com.

Dan Elphick

unread,
Feb 12, 2020, 8:28:28 AM2/12/20
to v8-u...@googlegroups.com
I've built v8's d8 at 7.1, 7.9 and HEAD and 7.1 is a little faster for the test you posted in your first email, but there's not much in it. Certainly nothing near the 600x slowdown you had. I wonder if you're setting any other flags either at runtime or build time?

To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/d649c0ed-d996-4dfa-b387-5e65caeaf45f%40googlegroups.com.

Wilfried Gösgens

unread,
Feb 12, 2020, 9:42:22 AM2/12/20
to v8-users
This 600x slowdown was inside of arangosh due to pasting - its not there anymore in the numbers of my previous post - sorry I didn't mention it explicitely. 

However, if you compare the numbers of my previous post, there still is an offset of ~40% which I'd still call significant?

Dan Elphick

unread,
Feb 12, 2020, 4:43:12 PM2/12/20
to v8-u...@googlegroups.com
When I ran the test in d8 (unfortunately I didn't keep the old binaries around so can't quickly verify) I saw at most a 10% difference between 7.1 vs 7.9.

Is this manifesting somewhere other than in your micro benchmark? Because this looks to be pretty much the worst case scenario, the function doesn't do anything except construct an Error object which requires constructing a stack trace and it needs to build 9 frames each time, but unless this is causing a problem in real code, I'm not sure how much attention it warrants.

On Wed, 12 Feb 2020 at 14:42, Wilfried Gösgens <doth...@gmail.com> wrote:
This 600x slowdown was inside of arangosh due to pasting - its not there anymore in the numbers of my previous post - sorry I didn't mention it explicitely. 

However, if you compare the numbers of my previous post, there still is an offset of ~40% which I'd still call significant?

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.

Wilfried Goesgens

unread,
Feb 13, 2020, 5:32:57 AM2/13/20
to v8-users
No, 
I wanted to demonstrate the Improvements of the New V8 release, found the stacktraces prominent on the changelog lists; Thus I created a test to give me some estimates, and was disappointed with my findings ;-) If there is a better way to test it, please give me an example. 
Cheers, 
Willi


Am Mittwoch, 12. Februar 2020 22:43:12 UTC+1 schrieb Dan Elphick:
When I ran the test in d8 (unfortunately I didn't keep the old binaries around so can't quickly verify) I saw at most a 10% difference between 7.1 vs 7.9.

Is this manifesting somewhere other than in your micro benchmark? Because this looks to be pretty much the worst case scenario, the function doesn't do anything except construct an Error object which requires constructing a stack trace and it needs to build 9 frames each time, but unless this is causing a problem in real code, I'm not sure how much attention it warrants.

On Wed, 12 Feb 2020 at 14:42, Wilfried Gösgens <doth...@gmail.com> wrote:
This 600x slowdown was inside of arangosh due to pasting - its not there anymore in the numbers of my previous post - sorry I didn't mention it explicitely. 

However, if you compare the numbers of my previous post, there still is an offset of ~40% which I'd still call significant?

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-u...@googlegroups.com.

Simon Zünd

unread,
Feb 13, 2020, 6:07:19 AM2/13/20
to v8-users
The improvements are with respect to serializing stack traces, that is if you access {.stack} on an error object. Performance for error creation, that is walking the stack and collecting frames, regressed slightly since we do some more work upfront now.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/0e87e1f2-1814-4c93-8057-f2982b77f20c%40googlegroups.com.

Wilfried Gösgens

unread,
Feb 14, 2020, 8:20:13 AM2/14/20
to v8-users
ok, thanks. 

in other news, the foxx framework and other arangodb specific js that we add when spawning a new isolate is down from 21MB -> 18MB, and spawning an isolate has become allmost 10 times faster.
Nice!
Reply all
Reply to author
Forward
0 new messages