687306 - js-ctypes slow performances in JS: not trace-JITed

Status: NEW

(Core :: js-ctypes, defect)

Description

[Andrea Giammarchi]

Attachment: ctypes.perf.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.4+ (KHTML, like Gecko) Version/5.1 Safari/534.50

Steps to reproduce:

I confused js-ctypes with JS.next typed structs/arrays, I posted about js-ctypes and created a bench to realize ctypes are up to 10X slower ( or more ) than non typed JS objects, even if never used in a "dll" ( used only in JS )

Brendan Eich asked me to point this out here ... so here I am from:
http://webreflection.blogspot.com/2011/09/introduction-to-js-ctypes.html
and the es-discuss ml


Actual results:

this happened: http://www.3site.eu/examples/ctypes.perf.html
Save the file locally and enable the usage of js-ctypes extension in Firefox or others

Most likely you will see that ctypes are on average 10 times slower than JS objects


Expected results:

after the discussion in the ML I have no idea anymore, or better, it's the first time I write statically typed code in a dynamically interpreted programming language as JS is expecting a massive performances boost out of binary data but either I am not using binary data here or something went terribly wrong in the trace-JIT compiler since no external compiled library is used.

Comment 1

[Bobby Holley (:bholley)]

I don't know much about trace stuff, but I'd be happy to learn. Is this straightforward to do?

Comment 2

[Boris Zbarsky [:bzbarsky]]

First of all, tracejit is off by default now, so I wouldn't worry about it too much.

Second, what's the issue here?  Is it that using ctypes arrays or structs is slower than native arrays, especially native typed arrays?  Isn't that more or less expected, given that the latter can be done in inline jit code while the former have to go through the whole FFI song-and-dance?

Comment 3

[Boris Zbarsky [:bzbarsky]]

One other note: the test is comparing apples to oranges to start with (reading one pointer from the native array, a two-integer struct from the ctypes array, creating new objects in one of the typed array cases, using dead code in the other typed array case....)

Comment 4

[Boris Zbarsky [:bzbarsky]]

That all said, a profile of the ctypes case shows:

  12% under the SetName stub, mostly calling proxy_SetProperty (because window.foo is
      explicitly being set, not a global variable).
  26% under JSCompartment::wrap under the JSCrossCompartmentWrapper::get call that
      proxy_GetProperty makes under the GetElem stub.  About half of this is self time,
      and the other half is creating the new wrapper object.
   5% pushing dummy frames under JSCrossCompartmentWrapper::get
  11% security checks under JSWrapper::get (for
      xpc::FilteringWrapper<JSCrossCompartmentWrapper,xpc::ExposedPropertiesOnly>::enter).
  22% under the actual ctypes::ArrayType::Getter; most of this is malloc and JS_NewObject
      overhead triggered by ctypes::ConvertToJS.
   7% overhead under js_GetProperty but outside ArrayType::Getter; mostly self time in
      js_GetProperty and proptable searches.

Obvious questions: Why are we ending up with cross-compartment anything here?  And why is it so expensive?  That last does not bode well for compartment-per-global....

Comment 5

[Benjamin Smedberg]

Does that .jsm access is always cross-compartment? That could be painful, and ctypes is implemented as a JSM.

Comment 6

[Andrea Giammarchi]

I just wonder if in a case where no dll/lib is imported, typed stuff has to pass through the whole song-and-dance but as I have said, not sure this is a proper issue, surely performances look poor.

(In reply to Boris Zbarsky (:bz) from comment #2)
> First of all, tracejit is off by default now, so I wouldn't worry about it
> too much.
> 
> Second, what's the issue here?  Is it that using ctypes arrays or structs is
> slower than native arrays, especially native typed arrays?  Isn't that more
> or less expected, given that the latter can be done in inline jit code while
> the former have to go through the whole FFI song-and-dance?

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Does that .jsm access is always cross-compartment?

Oh, good point.  It may not be always, but certainly in the file:// + enablePrivilege case.  Testing performance of any code the involved enablePrivilege is sort of silly, since enablePrivilege implies expensive security checks all over.

> typed stuff has to pass through the whole song-and-dance

Yes, since you have to create the C-side structures no matter what: someone may well pass the JS reflection around to somewhere else where a DLL _is_ loaded.

Comment 8

[Benjamin Smedberg]

We should certainly consider either unifying typed arrays or allowing them to be passed through ctypes directly in some cases, but that shouldn't be this bug, since this one already has several topics!

Comment 9

[Andrea Giammarchi]

The test is comparing different ways to obtain similar scenario: a statically typed collection of Point2D VS normal JS.

Int32Array has two tests indeed to test access over an ArrayType, in this case the native Int32Array, and same constructor with inline object creation per each point.

Latter test is to compare the difference between static typed stuff and JS in the meaning of creating in a loop each point in the loop via new Point2D({x: value, y: value});

Since this would be extremely bad in therms of performances with typed Point2D, I simply add the literal object overhead to spot difference between native static and native static with typed static potential usage from web developers.

Not sure I clarified or messed up more the idea behind tho ... 

(In reply to Boris Zbarsky (:bz) from comment #3)
> One other note: the test is comparing apples to oranges to start with
> (reading one pointer from the native array, a two-integer struct from the
> ctypes array, creating new objects in one of the typed array cases, using
> dead code in the other typed array case....)

Comment 10

[Andrea Giammarchi]

(In reply to Boris Zbarsky (:bz) from comment #7)
> Testing performance of any code the involved
> enablePrivilege is sort of silly, since enablePrivilege implies expensive
> security checks all over.

I can create an add-on that does the same test if necessary ...

Comment 11

[Boris Zbarsky [:bzbarsky]]

> I can create an add-on that does the same test if necessary ...

The numbers would look pretty different.

But again, you're comparing a dedicated fast-path (typed arrays) to generic access-to-C-data-structures code.  The latter will be slower.

Comment 12

[Andrea Giammarchi]

(In reply to Boris Zbarsky (:bz) from comment #11)
> The numbers would look pretty different.

I'll check then

> But again, you're comparing a dedicated fast-path (typed arrays) to generic
> access-to-C-data-structures code.  The latter will be slower.

I got this, I don't get why these static data structures cannot go as fast as typed arrays if no external library is involved plus I ArrayType(ctypes.int) is a typed array, the equivalent of Int32Array, imo

Once again, I got this js-ctypes extension was not meant to speed up JS but again as JS developer I am quite confused about the meaning of typed in current JS status.

Feel free to close this bug if you think everything is OK, thanks.

Comment 13

[Luke Wagner [:luke]]

(In reply to Andrea Giammarchi from comment #12)
> I got this, I don't get why these static data structures cannot go as fast
> as typed arrays if no external library is involved plus I
> ArrayType(ctypes.int) is a typed array, the equivalent of Int32Array, imo

I agree this is initially surprising.  I think the simple answer is that there is no free lunch and, even given the extra type information, one needs to teach the jit compilers to understand and optimize based on this information and, so far, we haven't.

Hopefully we'll be able to kill two birds with one stone: once JS.next struct types implemented and optimized, it seems like we could rejigger js-ctypes to hit the same fast paths.

Comment 14

[Andrea Giammarchi]

Nicolas B. Pierron [:nbp] I wasn't expecting an update after 11 years but I am apparently incapable of editing my initial post.

Please remove that rotten link as I don't own that 3site dot eu domain anymore, thank you.