Binding overhead for DOMMatrix?

[Chris Harrelson]

Hi Elliott,

Today you mentioned that the binding code should be very fast at this point for sending javascript objects like DOMMatrix across to C++ land and back. That's great news.

Could you point me to an existing benchmark that can be adapted for some performance testing of its use in upcoming Canvas APIs?

Chris

[Elliott Sprehn]

How do you expect to use the API in canvas? Using DOMMatrix vs an array or something else all pay the same cost to pass data across the bindings when you send it to a canvas.

I think the concern of DOMMatrix was about wrapper creation and setting the fields of the matrix itself?

meade@ has a matrix demo for CSS Typed OM you might look at.

- E 

[Eddy Mead]

The matrix class in Typed OM is meant to contain a DOMMatrixReadonly, so I don't think that gets you anything. Right now the implementation in blink uses a platform/transforms/TransformationMatrix.h, so you could compare that with DOMMatrix until we update it I guess.

We have a polyfill of DOMMatrixReadonly here, although I haven't done any benchmarking of it. You could probably adapt it to compare its speed with the bindings version?

[Kentaro Hara]

On Thu, Aug 4, 2016 at 3:33 PM, Eddy Mead <me...@chromium.org> wrote:

The matrix class in Typed OM is meant to contain a DOMMatrixReadonly, so I don't think that gets you anything. Right now the implementation in blink uses a platform/transforms/TransformationMatrix.h, so you could compare that with DOMMatrix until we update it I guess.

We have a polyfill of DOMMatrixReadonly here, although I haven't done any benchmarking of it. You could probably adapt it to compare its speed with the bindings version?

Having a benchmark sounds nice. You can add it to PerformanceTests/Bindings/.

Unless you create a ton of DOMMarices, I don't think the binding version will affect performance.

On Thu, Aug 4, 2016 at 4:01 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Wed, Aug 3, 2016 at 10:28 PM, Chris Harrelson <chri...@chromium.org> wrote:

Hi Elliott,

Today you mentioned that the binding code should be very fast at this point for sending javascript objects like DOMMatrix across to C++ land and back. That's great news.

Could you point me to an existing benchmark that can be adapted for some performance testing of its use in upcoming Canvas APIs?

How do you expect to use the API in canvas? Using DOMMatrix vs an array or something else all pay the same cost to pass data across the bindings when you send it to a canvas.

I think the concern of DOMMatrix was about wrapper creation and setting the fields of the matrix itself?

meade@ has a matrix demo for CSS Typed OM you might look at.

- E 

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAGUgK4KGPSDRQrKgvRbbd6FYALQeh8MHjNXw%2BiNxq6KJ4R5AOA%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

[Chris Harrelson]

The use case is setting the transform on a CanvasPattern (bug). DOMMatrixReadOnly is the spec'ed object. Thanks for the pointers, we'll adapt a test.

On Thu, Aug 4, 2016 at 1:07 AM, Kentaro Hara <har...@chromium.org> wrote:

On Thu, Aug 4, 2016 at 3:33 PM, Eddy Mead <me...@chromium.org> wrote:

The matrix class in Typed OM is meant to contain a DOMMatrixReadonly, so I don't think that gets you anything. Right now the implementation in blink uses a platform/transforms/TransformationMatrix.h, so you could compare that with DOMMatrix until we update it I guess.

We have a polyfill of DOMMatrixReadonly here, although I haven't done any benchmarking of it. You could probably adapt it to compare its speed with the bindings version?

Having a benchmark sounds nice. You can add it to PerformanceTests/Bindings/.

Unless you create a ton of DOMMarices, I don't think the binding version will affect performance.

On Thu, Aug 4, 2016 at 4:01 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Wed, Aug 3, 2016 at 10:28 PM, Chris Harrelson <chri...@chromium.org> wrote:

Hi Elliott,

Today you mentioned that the binding code should be very fast at this point for sending javascript objects like DOMMatrix across to C++ land and back. That's great news.

Could you point me to an existing benchmark that can be adapted for some performance testing of its use in upcoming Canvas APIs?

How do you expect to use the API in canvas? Using DOMMatrix vs an array or something else all pay the same cost to pass data across the bindings when you send it to a canvas.

I think the concern of DOMMatrix was about wrapper creation and setting the fields of the matrix itself?

meade@ has a matrix demo for CSS Typed OM you might look at.

- E 

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAGUgK4KGPSDRQrKgvRbbd6FYALQeh8MHjNXw%2BiNxq6KJ4R5AOA%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jzs2M%3D719iK3rNQ4f-mJiUx5H3kxN3ThprpDJyNLiOa3w%40mail.gmail.com.

[xlai]

I just had a short discussion with vollick@ and jbroman@ and we are thinking if it's possible to ship DOMMatrixReadOnly first without shipping DOMMatrix itself.

For that canvas API that Chris mentioned, what we need is just a read-only matrix; we don't need its "liveness" or setters. (In fact it doesn't even need to be 3D as canvas pattern works on 2d canvas rendering context but this is off-topic). The same situation applies to compositor worker, where a read-only matrix is needed. The performance concern raised by this thread (and a subsequent failed attempt to address the performance concern by using V8 Extras) shouldn't be blocking these APIs that depend on read-only matrix.

In addition, I can also explore the option of shipping CanvasPattern.setTransform(DOMMatrixInit) without exposing DOMMatrix or DOMMatrixReadOnly to users. In this option, the dictionary DOMMatrixInit needs to be implemented.

On Thu, Aug 4, 2016 at 12:52 PM, Chris Harrelson <chri...@chromium.org> wrote:

The use case is setting the transform on a CanvasPattern (bug). DOMMatrixReadOnly is the spec'ed object. Thanks for the pointers, we'll adapt a test.

On Thu, Aug 4, 2016 at 1:07 AM, Kentaro Hara <har...@chromium.org> wrote:

On Thu, Aug 4, 2016 at 3:33 PM, Eddy Mead <me...@chromium.org> wrote:

The matrix class in Typed OM is meant to contain a DOMMatrixReadonly, so I don't think that gets you anything. Right now the implementation in blink uses a platform/transforms/TransformationMatrix.h, so you could compare that with DOMMatrix until we update it I guess.

We have a polyfill of DOMMatrixReadonly here, although I haven't done any benchmarking of it. You could probably adapt it to compare its speed with the bindings version?

Having a benchmark sounds nice. You can add it to PerformanceTests/Bindings/.

Unless you create a ton of DOMMarices, I don't think the binding version will affect performance.

On Thu, Aug 4, 2016 at 4:01 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Wed, Aug 3, 2016 at 10:28 PM, Chris Harrelson <chri...@chromium.org> wrote:

Hi Elliott,

Today you mentioned that the binding code should be very fast at this point for sending javascript objects like DOMMatrix across to C++ land and back. That's great news.

Could you point me to an existing benchmark that can be adapted for some performance testing of its use in upcoming Canvas APIs?

How do you expect to use the API in canvas? Using DOMMatrix vs an array or something else all pay the same cost to pass data across the bindings when you send it to a canvas.

I think the concern of DOMMatrix was about wrapper creation and setting the fields of the matrix itself?

meade@ has a matrix demo for CSS Typed OM you might look at.

- E 

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAGUgK4KGPSDRQrKgvRbbd6FYALQeh8MHjNXw%2BiNxq6KJ4R5AOA%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

[Chris Harrelson]

Yes, the "liveness" performance issue shouldn't block DOMMatrixReadOnly, but there is still the need to performance test raw use of DOMMatrixReadOnly, to see how it scales, and in particular how much overhead there is in converting from v8 to C++ type representations. It sounds like it should be straightforward to add such a performance test, so why not?

Chris

[xlai]

I have written a simple performance test in JavaScript to compare the performance between polyfill and native DOMMatrixReadOnly, with a focus on multiplication operation time and constructor time. It constructs 4000 matrices and does a total of 3000 multiplication among themselves.

The polyfill is based on the DOMMatrixReadOnly polyfill that Eddy has suggested. The native DOMMatrixReadOnly is based on Chromium DOMMatrixReadOnly object when GeometryInterfaces feature flag is enabled, plus my addition of new constructors and new multiplication operations to DOMMatrixReadOnly (Note that the current implementation of DOMMatrixReadOnly doesn't have convenient constructors and operators for me to use; so I have to copy a little bit code from DOMMatrix).

I ran it a few times and every time the native performs much better than the polyfill (the shorter time it takes, the better). For example, in one of my latest run, the test displays:

Polyfill duration :

multiply operation takes 6 ms; constructor operation takes 11 ms.

Native duration :

multiply operation takes 2ms; constructor operation takes 9 ms.

I know the test is a bit simplistic here but I think it already shows something that we want to know. Those in charge of DOMMatrix could move ahead and write more sophisticated tests for all matrix operations (not just multiplication) exhaustively to further verify this result.

[xlai]

(+cc style-dev)

My conclusion from a simple perf test result (see previous email) was that the native DOMMatrixReadOnly works better than polyfill, both in constructors and multiply operation.

I was thinking of moving ahead to implement and ship DOMMatrixReadOnly, before I realize something weird about the spec and I hope to seek answers within Chromium before I reach out to w3.org:

DOMMatrixReadOnly has many transformation operations about DOMMatrix. Why is this the case? Shouldn't DOMMatrixReadOnly interface contain functions that operate on itself? For example, there is a function called "DOMMatrix multiply(DOMMatrix other);" under the DOMMatrixReadOnly interface; my feeling is that it should be "DOMMatrixReadOnly multiply(DOMMatrixReadOnly other);". 

[Domenic Denicola]

I think the return type being DOMMatrix makes sense; DOMMatrixReadonly is mostly about user-agent-created matrices that must be immutable. However, for multiply() the argument should probably be a DOMMatrixInit. I think that's a spec bug that should be filed.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAGUgK4KGPSDRQrKgvRbbd6FYALQeh8MHjNXw%2BiNxq6KJ4R5AOA%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jzs2M%3D719iK3rNQ4f-mJiUx5H3kxN3ThprpDJyNLiOa3w%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CADHjF%2BH2g57U4hdV7UPKOAFuGNVYb6-_YPn7EQ8yK5U2M01TzA%40mail.gmail.com.

[Ian Vollick]

Liveness has been a real concern with this API and this issue goes away if we use read only matrices.

Immutable matrices would be also be more common in APIs, no?

IIUC, with Olivia's proposal, matrices would usually be read only, particularly the result of matrix operations. You'd need to explicitly construct a DOMMatrix with your DOMMatrixReadOnly if you wanted to mutate the components. I'm sure I'm missing subtlety, but it seems like a good idea to make the more performant version the norm.

On Tue, Aug 16, 2016 at 11:55 AM xlai <xl...@chromium.org> wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAGUgK4KGPSDRQrKgvRbbd6FYALQeh8MHjNXw%2BiNxq6KJ4R5AOA%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

[xlai]

Yes, I propose to expose DOMMatrixReadOnly first, because this interface is more commonly used in multiple canvas APIs (e.g. CanvasPattern.setTransform, CanvasRenderingContext2D.getTransform, etc.) and it does not have the liveness performance problem as what DOMMatrix does. I'm not sure how the liveness problem can be solved but it seems to be that it cannot be done in near future (crbug.com/388780 has been hanging for more than 2 years). Instead of keeping the whole geometry interfaces blocked (and then blocking other APIs from shipping), do you think it would be better that we make some adjustment on DOMMatrixReadOnly spec to make it a standalone interface and then ship it first?

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAGUgK4KGPSDRQrKgvRbbd6FYALQeh8MHjNXw%2BiNxq6KJ4R5AOA%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

[Chris Harrelson]

On Thu, Aug 11, 2016 at 9:33 AM, xlai <xl...@chromium.org> wrote:

I have written a simple performance test in JavaScript to compare the performance between polyfill and native DOMMatrixReadOnly, with a focus on multiplication operation time and constructor time. It constructs 4000 matrices and does a total of 3000 multiplication among themselves.

The polyfill is based on the DOMMatrixReadOnly polyfill that Eddy has suggested. The native DOMMatrixReadOnly is based on Chromium DOMMatrixReadOnly object when GeometryInterfaces feature flag is enabled, plus my addition of new constructors and new multiplication operations to DOMMatrixReadOnly (Note that the current implementation of DOMMatrixReadOnly doesn't have convenient constructors and operators for me to use; so I have to copy a little bit code from DOMMatrix).

I ran it a few times and every time the native performs much better than the polyfill (the shorter time it takes, the better). For example, in one of my latest run, the test displays:

Polyfill duration :

multiply operation takes 6 ms; constructor operation takes 11 ms.

Native duration :

multiply operation takes 2ms; constructor operation takes 9 ms.

I know the test is a bit simplistic here but I think it already shows something that we want to know. Those in charge of DOMMatrix could move ahead and write more sophisticated tests for all matrix operations (not just multiplication) exhaustively to further verify this result.

Hi Olivia, just back from vacation, hence the slow reply.

It's great that it is faster than the polyfill. The second question is how much slower it is than the equivalent in pure C++ using TransformationMatrix, and how much of the overhead vs that theoretical maximum speed is due to bindings or other overhead. Do you have that data?

 

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CADHjF%2BH2kfLF_PKtV4aW43JVdt%2BPcG8vMO-XYGajxzHgQ%2BqGEg%40mail.gmail.com.

[xlai]

Unfortunately I don't have that data; it might be better for someone familiar with the internal implementation on binding to write a perf test for that particular aspect.

The latest progress on this issue: we might be trying to propose changes to the spec of DOMMatrixReadOnly to make it a standalone interface. In that way, the liveness performance problem of DOMMatrix will not block DOMMatrixReadOnly from being used. That will release those canvas APIs (and a few use cases elsewhere that just need a read-only matrix) that have been blocked by this.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CADHjF%2BH2kfLF_PKtV4aW43JVdt%2BPcG8vMO-XYGajxzHgQ%2BqGEg%40mail.gmail.com.

[Chris Harrelson]

On Fri, Aug 26, 2016 at 8:14 AM, xlai <xl...@chromium.org> wrote:

Unfortunately I don't have that data; it might be better for someone familiar with the internal implementation on binding to write a perf test for that particular aspect.

The latest progress on this issue: we might be trying to propose changes to the spec of DOMMatrixReadOnly to make it a standalone interface. In that way, the liveness performance problem of DOMMatrix will not block DOMMatrixReadOnly from being used. That will release those canvas APIs (and a few use cases elsewhere that just need a read-only matrix) that have been blocked by this.

It would also be nice to just rename DOMMatrixReadOnly to DOMMatrix and get rid of the liveness property.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CADHjF%2BEoZh9Vf%2B8%2B4CG1q2gnRFc6wKr0f%3DGYHnD1Ahs6uhmU5Q%40mail.gmail.com.

[hs1217.lee]

hi. guys.

these day, i am working to implement DOMMatrix.

and i created github repository for performance test.

link is (https://github.com/hwanseung/DOMMatrixPerformanceTest)

there are two result.

first result is current implement status.

polyfill is faster than native about 40 times in my local computer.

navtive is too slower. so i uploaded new patch to improve performance.

it is using DOMMatrixReadOnly instead of DOMMatrixInit as parameter at multiply() function.

second result was applied new patch.

polyfill is faster than native about 2 times in my local computer.

how do you think about two result?

if you want test in your computer, visit https://hwanseung.github.io/DOMMatrixPerformanceTest

ps. if test page were not suitable, please tell me about problem.

[Jochen Eisinger]

+Domenic Denicola who said he'd look into writing JS based spec compliant bindings at some point

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/2d3f611c-05c0-4156-8faa-013baa016fa3%40chromium.org.

[Domenic Denicola]

I spent some more time on this today. The results are at https://github.com/domenic/v8-extras-geometry, and don't yet include DOMMatrixReadOnly, but they might by the time you read this.

One thing I did notice immediately though is that the benchmark doesn't seem to be fair. The polyfill only accepts DOMMatrixReadOnly, and does not accept an arbitrary DOMMatrixInit. This means the polyfill gets to avoid spending all the time going through the per-Web IDL-spec process of pulling elements off of the dictionary, which generates a lot of code, and then per the Geometry spec you further need to normalize the resulting dictionary into a usable matrix before performing the actual multiplication.

This aligns with the fact that you get such a speedup by changing the bindings to require a DOMMatrixReadOnly argument; it gets to skip both of those steps (like the polyfill already does).

So although I intend to continue investigating what the results would look like in a JS-based spec complaint binding, my initial thoughts are that at least a part of the problem is the different algorithms in use. Hopefully we'll be able to quantify how much when I complete my investigation.

[Domenic Denicola]

I have to go for the day, but I put together a hacked-together DOMMatrixReadOnly and a benchmark for it based on Hwanseung's benchmark. You can view it at https://rawgit.com/domenic/v8-extras-geometry/master/bench/index.html .

The results show a decent advantage for native, ranging from 5x for 10 runs to 1.3x for 100K runs. However, doing some preliminary profiling I am noticing some deopts and other issues, so it's probable the JS code could be cleaned up to run faster. The preliminary profiling also suggests that the dictionary conversion is minimal overhead, which is a bit surprising to me; maybe if I wasn't deopting then it would come to the forefront.

I might be able to give that a try myself; if others want to look at it I'd suggest messing around with https://github.com/domenic/v8-extras-geometry/blob/dfaff8a336669951457ceab28953ba0d7966b8d5/bench/DOMMatrixReadOnly-and-support.js#L288-L307 directly.

[Elliott Sprehn]

In general we're not very concerned with DOMMatrix native performance these days, I think we should ship it.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

[Domenic Denicola]

On Wed, Jan 4, 2017 at 6:48 PM Domenic Denicola <dom...@google.com> wrote:

I have to go for the day, but I put together a hacked-together DOMMatrixReadOnly and a benchmark for it based on Hwanseung's benchmark. You can view it at https://rawgit.com/domenic/v8-extras-geometry/master/bench/index.html .

The results show a decent advantage for native, ranging from 5x for 10 runs to 1.3x for 100K runs. However, doing some preliminary profiling I am noticing some deopts and other issues, so it's probable the JS code could be cleaned up to run faster. The preliminary profiling also suggests that the dictionary conversion is minimal overhead, which is a bit surprising to me; maybe if I wasn't deopting then it would come to the forefront.

I might be able to give that a try myself; if others want to look at it I'd suggest messing around with https://github.com/domenic/v8-extras-geometry/blob/dfaff8a336669951457ceab28953ba0d7966b8d5/bench/DOMMatrixReadOnly-and-support.js#L288-L307 directly.

After fixing a stupid bug the spec-compliant generated polyfill is now generally 2x faster than native and I no longer see deopts.

[Elliott Sprehn]

On Wed, Jan 4, 2017 at 3:58 PM, 'Domenic Denicola' via platform-architecture-dev <platform-arc...@chromium.org> wrote:

On Wed, Jan 4, 2017 at 6:48 PM Domenic Denicola <dom...@google.com> wrote:

I have to go for the day, but I put together a hacked-together DOMMatrixReadOnly and a benchmark for it based on Hwanseung's benchmark. You can view it at https://rawgit.com/domenic/v8-extras-geometry/master/bench/index.html .

The results show a decent advantage for native, ranging from 5x for 10 runs to 1.3x for 100K runs. However, doing some preliminary profiling I am noticing some deopts and other issues, so it's probable the JS code could be cleaned up to run faster. The preliminary profiling also suggests that the dictionary conversion is minimal overhead, which is a bit surprising to me; maybe if I wasn't deopting then it would come to the forefront.

I might be able to give that a try myself; if others want to look at it I'd suggest messing around with https://github.com/domenic/v8-extras-geometry/blob/dfaff8a336669951457ceab28953ba0d7966b8d5/bench/DOMMatrixReadOnly-and-support.js#L288-L307 directly.

After fixing a stupid bug the spec-compliant generated polyfill is now generally 2x faster than native and I no longer see deopts.

That sounds like a bug in our bindings we should fix. Where is the time spent in the C++?

 

 

On Wed, Jan 4, 2017 at 5:12 PM Domenic Denicola <dom...@google.com> wrote:

I spent some more time on this today. The results are at https://github.com/domenic/v8-extras-geometry, and don't yet include DOMMatrixReadOnly, but they might by the time you read this.

One thing I did notice immediately though is that the benchmark doesn't seem to be fair. The polyfill only accepts DOMMatrixReadOnly, and does not accept an arbitrary DOMMatrixInit. This means the polyfill gets to avoid spending all the time going through the per-Web IDL-spec process of pulling elements off of the dictionary, which generates a lot of code, and then per the Geometry spec you further need to normalize the resulting dictionary into a usable matrix before performing the actual multiplication.

This aligns with the fact that you get such a speedup by changing the bindings to require a DOMMatrixReadOnly argument; it gets to skip both of those steps (like the polyfill already does).

So although I intend to continue investigating what the results would look like in a JS-based spec complaint binding, my initial thoughts are that at least a part of the problem is the different algorithms in use. Hopefully we'll be able to quantify how much when I complete my investigation.

On Mon, Jan 2, 2017 at 10:30 AM Jochen Eisinger <joc...@chromium.org> wrote:

+Domenic Denicola who said he'd look into writing JS based spec compliant bindings at some point

On Mon, Jan 2, 2017 at 4:22 PM hs1217.lee <hs121...@samsung.com> wrote:

hi. guys.

these day, i am working to implement DOMMatrix.

and i created github repository for performance test.

link is (https://github.com/hwanseung/DOMMatrixPerformanceTest)

there are two result.

first result is current implement status.

polyfill is faster than native about 40 times in my local computer.

navtive is too slower. so i uploaded new patch to improve performance.

it is using DOMMatrixReadOnly instead of DOMMatrixInit as parameter at multiply() function.

second result was applied new patch.

polyfill is faster than native about 2 times in my local computer.

how do you think about two result?

if you want test in your computer, visit https://hwanseung.github.io/DOMMatrixPerformanceTest

ps. if test page were not suitable, please tell me about problem.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/2d3f611c-05c0-4156-8faa-013baa016fa3%40chromium.org.

--

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAM0wra-rpKQh4dgaQsqFpcOaa_%2BMrjibfNbHr00GVQqNk3pj0Q%40mail.gmail.com.

[Chris Harrelson]

On Wed, Jan 4, 2017 at 4:07 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Wed, Jan 4, 2017 at 3:58 PM, 'Domenic Denicola' via platform-architecture-dev <platform-architecture-dev@chromium.org> wrote:

On Wed, Jan 4, 2017 at 6:48 PM Domenic Denicola <dom...@google.com> wrote:

I have to go for the day, but I put together a hacked-together DOMMatrixReadOnly and a benchmark for it based on Hwanseung's benchmark. You can view it at https://rawgit.com/domenic/v8-extras-geometry/master/bench/index.html .

The results show a decent advantage for native, ranging from 5x for 10 runs to 1.3x for 100K runs. However, doing some preliminary profiling I am noticing some deopts and other issues, so it's probable the JS code could be cleaned up to run faster. The preliminary profiling also suggests that the dictionary conversion is minimal overhead, which is a bit surprising to me; maybe if I wasn't deopting then it would come to the forefront.

I might be able to give that a try myself; if others want to look at it I'd suggest messing around with https://github.com/domenic/v8-extras-geometry/blob/dfaff8a336669951457ceab28953ba0d7966b8d5/bench/DOMMatrixReadOnly-and-support.js#L288-L307 directly.

After fixing a stupid bug the spec-compliant generated polyfill is now generally 2x faster than native and I no longer see deopts.

That sounds like a bug in our bindings we should fix. Where is the time spent in the C++?

I just reproduced this 2x problem, and collected a CPU profile of running the benchmark locally. All of the top overhead was in V8-bindings-related functions as far as I can tell. I filed crbug.com/685748. I think this perf issue should block a launch of DOMMatrix{ReadOnly}.

 

 

 

On Wed, Jan 4, 2017 at 5:12 PM Domenic Denicola <dom...@google.com> wrote:

I spent some more time on this today. The results are at https://github.com/domenic/v8-extras-geometry, and don't yet include DOMMatrixReadOnly, but they might by the time you read this.

One thing I did notice immediately though is that the benchmark doesn't seem to be fair. The polyfill only accepts DOMMatrixReadOnly, and does not accept an arbitrary DOMMatrixInit. This means the polyfill gets to avoid spending all the time going through the per-Web IDL-spec process of pulling elements off of the dictionary, which generates a lot of code, and then per the Geometry spec you further need to normalize the resulting dictionary into a usable matrix before performing the actual multiplication.

This aligns with the fact that you get such a speedup by changing the bindings to require a DOMMatrixReadOnly argument; it gets to skip both of those steps (like the polyfill already does).

So although I intend to continue investigating what the results would look like in a JS-based spec complaint binding, my initial thoughts are that at least a part of the problem is the different algorithms in use. Hopefully we'll be able to quantify how much when I complete my investigation.

On Mon, Jan 2, 2017 at 10:30 AM Jochen Eisinger <joc...@chromium.org> wrote:

+Domenic Denicola who said he'd look into writing JS based spec compliant bindings at some point

On Mon, Jan 2, 2017 at 4:22 PM hs1217.lee <hs121...@samsung.com> wrote:

hi. guys.

these day, i am working to implement DOMMatrix.

and i created github repository for performance test.

link is (https://github.com/hwanseung/DOMMatrixPerformanceTest)

there are two result.

first result is current implement status.

polyfill is faster than native about 40 times in my local computer.

navtive is too slower. so i uploaded new patch to improve performance.

it is using DOMMatrixReadOnly instead of DOMMatrixInit as parameter at multiply() function.

second result was applied new patch.

polyfill is faster than native about 2 times in my local computer.

how do you think about two result?

if you want test in your computer, visit https://hwanseung.github.io/DOMMatrixPerformanceTest

ps. if test page were not suitable, please tell me about problem.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/2d3f611c-05c0-4156-8faa-013baa016fa3%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.

To post to this group, send email to platform-architecture-dev@chromium.org.

[Chris Harrelson]

On Thu, Jan 26, 2017 at 12:04 PM, Chris Harrelson <chri...@chromium.org> wrote:

On Wed, Jan 4, 2017 at 4:07 PM, Elliott Sprehn <esp...@chromium.org> wrote:

On Wed, Jan 4, 2017 at 3:58 PM, 'Domenic Denicola' via platform-architecture-dev <platform-architecture-dev@chromium.org> wrote:

On Wed, Jan 4, 2017 at 6:48 PM Domenic Denicola <dom...@google.com> wrote:

I have to go for the day, but I put together a hacked-together DOMMatrixReadOnly and a benchmark for it based on Hwanseung's benchmark. You can view it at https://rawgit.com/domenic/v8-extras-geometry/master/bench/index.html .

The results show a decent advantage for native, ranging from 5x for 10 runs to 1.3x for 100K runs. However, doing some preliminary profiling I am noticing some deopts and other issues, so it's probable the JS code could be cleaned up to run faster. The preliminary profiling also suggests that the dictionary conversion is minimal overhead, which is a bit surprising to me; maybe if I wasn't deopting then it would come to the forefront.

I might be able to give that a try myself; if others want to look at it I'd suggest messing around with https://github.com/domenic/v8-extras-geometry/blob/dfaff8a336669951457ceab28953ba0d7966b8d5/bench/DOMMatrixReadOnly-and-support.js#L288-L307 directly.

After fixing a stupid bug the spec-compliant generated polyfill is now generally 2x faster than native and I no longer see deopts.

That sounds like a bug in our bindings we should fix. Where is the time spent in the C++?

I just reproduced this 2x problem, and collected a CPU profile of running the benchmark locally. All of the top overhead was in V8-bindings-related functions as far as I can tell. I filed crbug.com/685748. I think this perf issue should block a launch of DOMMatrix{ReadOnly}.

Some progress has been made on 685748, which is also admittedly a microbenchmark. I'm ok with shipping this if there is no other objection, and the bindings experts feel that there is a reasonable path to drive down the overhead over time if necessary.

Thanks everyone for your attention to this issue.

[Elliott Sprehn]

+1, ship it! :D

[Kentaro Hara]

I'm fine with shipping it assuming that the regression is observed only on micro-benchmarks.