Laminar submission to js-framework-benchmark

[dabrowski-adam]

Recently, I set out to try frontend development in Scala; when deciding what framework to start with, I had a look at the js-framework-benchmark but the only Scala.js framework present there is Binding.scala. Eventually, I decided to go with Laminar and I thought that adding it to the benchmark would make a good first project.

My PR is already up: krausest/js-framework-benchmark#1599

However, I don't want to misrepresent the performance of Laminar, so I'd be grateful if someone more experienced checked if I'm not doing anything obviously wrong.

[raquo]

Hi, that's great, thanks! One thing off my list that I probably would have never found the time for :)

The Laminar part looks as good as it gets in realistic conditions, if using the declarative children <-- pattern, which is almost always preferable. children.command would likely be faster, but honestly it has very limited applications, and wouldn't be a good fit for this benchmark, I don't think you should use it in a general-purpose benchmark, children + split is indeed the way to go here.

There's some room for improvement in auxiliary aspects, in no particular order:

1. You can disable duplicate key checks for your split call, see here: https://github.com/raquo/Airstream/?tab=readme-ov-file#duplicate-key-warnings - it won't affect behaviour, but will avoid printing an error to the console when invalid input is detected (and will thus avoid collecting the information needed for that, which might give a small boost in perf).
2. You can optimize Scala collection calls. for example, .zipWithIndex.map is convenient, but it's creating an intermediary collection. filterNot is convenient, but it keeps checking the id for every item, even after finding one (and we only expect one). These can be optimized, but it will look uglier.
3. You may want to try to use a different data structure. In JS, native JS arrays are almost always the fastest. You can try JsVector from https://github.com/raquo/ew but it's a dependency of Laminar, and you will need to upgrade to Laminar 17.0.0-M6 to use a more reasonable version of ew. However, note the README of ew – this is not free lunch, you lose Scala semantics.

In real life, you wouldn't bother to do any of this every time, but in that one case where you're actually performance-constrained, you may want to do such things. So, I'm not sure what would be more honest / representative for this benchmark, the default case, or the optimized to death case, or something in between.

I'm also not sure how much any of this will improve the performance. Using ew's JsVector / JsArray internally in Laminar certainly helped, because on scala-semantics collections like Vector and js.Array, indexOf is O(n) whereas in native JS arrays it's, well, I don't know what exactly, but it's orders of magnitude faster than Scala's O(n) on large enough datasets. And since we have indexOf calls in a loop inside children <-- , we were able to effectively mitigate this loop being O(n^2) by switching to raw JS types, but the same kind of improvement might not be available in this benchmark's user code.

[dabrowski-adam]

Thanks a lot for the review, @raquo! I implemented some of the improvements you suggested: krausest/js-framework-benchmark@01d588b

Currently, the Achilles heel of my implementation is swapping rows, so if I find the time, I'll swap the Vector out for a different data structure. :)

[dabrowski-adam]

You can find the official measurements of my initial implementation (using Scala Vector) in the most recent run of the benchmark:

https://krausest.github.io/js-framework-benchmark/2024/table_chrome_122.0.6261.69.html

[raquo]

Well, I tried to diagnose this benchmark's results a few days ago, but sadly, no success. Unfortunately I have no idea if this benchmark reflects the actual speed or not.

I tried to profile the benchmark using browser dev tools when running it locally (clicking the ui buttons manually) but I couldn't get useful results. I'm not sure if something's wrong with vite or sourcemaps or what, but when I did profiling last year for 0.14.x, the profiling dev tools gave me actionable information, showing me how much time the cpu spends on each line of code while looking at the laminar source code in browser dev tools, but I can't seem to find this functionality in the dev tools now. And, on a high level, last time I was able to parse out insights like "~80% of cpu time was spent on the browser DOM API calls", but now I'm not seeing this. Or, maybe it's the vite setup or the lack of GCC optimization in vite that makes those numbers appear nonsensical, I don't know.

I wanted to find the source code that is run for any given benchmark, specifically I wanted to see when does the benchmark timing start, and when does it stop, and what happens between the "warmup" runs and the measured run, because e.g. it would make a big difference whether the "create rows" benchmark includes the time it takes to destroy the previously created rows in its measurement. I'm sure it's there somewhere but I didn't find anything that would clearly show that, so I don't know what exactly it measures.

I wanted to switch out Vector for a different data structure and see if it gets faster, but running their benchmark in the browser UI does not print out the time that the benchmark would have measured from that run. They have some convoluted setup for running benchmarks in a headless browser and logging the results to a file, and I'm sure that it's useful for compiling their tables, but it's not very useful for debugging / comparing variations of your benchmark and profiling them using browser dev tools.

Anyway, unfortunately there's too much pain and too little clarity in this setup for me to do anything about it. I don't like seeing Laminar in the red, but as it stands, I don't have the tools to act on it. When someone reported actual slowness back in 0.14 (#108), I was able to reproduce the problem in my own benchmarks, and fixed it. But now I see the red in this benchmark, and I don't see a way to translate that red into actionable insights.

---

If you want to try js.Array or ew.JsVector instead of Scala Vector, you'll need to use Laminar 17.0.0-M8 – in that version you can even feed mutable arrays to Laminar. Otherwise the API of v17 is pretty much exactly the same as far as your benchmark code is concerned. But, I think most of the benefit will be from using any JS collection type, even js.Array.