WebAssembly/stringref

Performance report for kotlin wasm compiler

igoriakovlev opened this issue · 3 comments

igoriakovlev commented

Hi,
We have some stringref experiment results concerning stringref proposal.

We compared two different string implementations using chars array and stringref reference implementations. We rewritten dom-monster the benchmark (which using DOM a lot) from JS into the Kotlin and compiled it into the Wasm with and w/o stringref support. The results were measured with two ways: DevTools framerate stats and perf-monitor (that was applied only to DOM updating part of benchmark code).

We got next results:

  • DevTools frame rate shows us up to 25% performance boost for stringref implementation (whatever it means for timer firing update of DOM nodes).

  • perf-monitor shows about x3.5 performance boost for stringref (that hardly depends on benchmark parameters) over classic string implementations.

The profile we got for classic string implementation shows that at least 10% of all CPU time was spent for Kotlin to JS conversions.

ecmziegler commented

These are very encouraging numbers! Can you explain in a little more detail how those three data points compare against each other?

  • The 25% frame rate improvement seems high compared to the >10% spent in string conversions. Is that because the 10% also cover other parts of the code that take a large portion of the computation time or could the time spent in string conversions actually be much higher than 10%?
  • I assume the 3.5x improvement only covers the actual string operations or is it indeed all of the DOM updates?

Thank you!

igoriakovlev commented

Hi @ecmziegler

  • Yes, that 10% I got for own time of our conversion function from Kotlin string into JS string (it works with memory buffer, so for every string that goes over the Wasm-JS border there is double copying happens). This 10% is a part of whole benchmark execution time.
  • As I see, this 3.5x upgrade is measured only for the code frame that actually updates DOM. It use external JS functions that operates DOM on JS side. I don't really know how DOM update works in Chrome (is it updates and render updated DOM immediately or postpone it somehow).

I can share with you instructions how to reproduce this benchmark if you would like to dive into it.

Igor

Pauan commented

@igoriakovlev I don't really know how DOM update works in Chrome (is it updates and render updated DOM immediately or postpone it somehow).

All browsers delay updates until the next animation frame (or if you use certain APIs, like clientWidth or getBoundingClientRect).

This means that the browser batches multiple updates together, and the actual DOM updating is delayed until later.

  • 👍1