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?

On Wed, 12 Feb 2020 at 12:28, Wilfried Gösgens <dotheb...@gmail.com> wrote:

> 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
>
> On Monday, February 10, 2020 at 5:03:29 PM UTC+1, Dan Elphick wrote:
>>
>> 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
>>
>> On Mon, 10 Feb 2020 at 15:20, Wilfried Gösgens <doth...@gmail.com> wrote:
>>
>>> 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
>>>
>>> --
>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/v8-users/f27ad537-86c5-4f3e-be8c-b25b73dea7af%40googlegroups.com
>>> <https://groups.google.com/d/msgid/v8-users/f27ad537-86c5-4f3e-be8c-b25b73dea7af%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> --
> v8-users mailing list
> v8-users@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+unsubscr...@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
> <https://groups.google.com/d/msgid/v8-users/d649c0ed-d996-4dfa-b387-5e65caeaf45f%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
-- 
v8-users mailing list
v8-users@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CALH_77vnTKaA%2B-s-1SPoCH-puNFq-qkgVsBgbe_z2FemM8%3Do4g%40mail.gmail.com.

Reply via email to