Results for chrome 142 are uploaded.
After some improvements in the last chrome version, chrome 142 turned out to be slower than chrome 141 - mostly for create rows.

Due to the problems with chrome for testing we're still using the chrome desktop version.

Attached you find a binary build of all frameworks such that you can run the benchmark without installing and building all frameworks (see README for how to use the build.zip)

I'm currently trying to cope with the long duration for full runs see #1930 . In this run two memory benchmarks were thus skipped: For update rows and create 10k rows. This helped me complete the full run in way less time. I'll update #1930 with further insights.

Results for chrome 141 are uploaded.
Looks very, very similar to chrome 140 results.

Due to the problems with chrome for testing we're still using the chrome desktop version.

Attached you find a binary build of all frameworks such that you can run the benchmark without installing and building all frameworks (see README for how to use the build.zip)

The run took almost 14 hours on my machine see #1930 for a discussion how to improve it.

Results for chrome 140 are uploaded.
No big changed from chrome 139 for this benchmark.

Due to the problems with chrome for testing we're still using the chrome desktop version.

Attached you find a binary build of all frameworks such that you can run the benchmark without installing and building all frameworks (see README for how to use the build.zip)

Results for chrome 139 are uploaded.
Seems like almost no change from 138 (which was pretty fast)

Due to the problems with chrome for testing we're still using the chrome desktop version.

Attached you find a binary build of all frameworks such that you can run the benchmark without installing and building all frameworks (see README for how to use the build.zip)

Since chrome 137 we're publishing non-keyed results (to express my dislike) only for even chrome versions to save time (so to say we're answering the inept non-keyed optimization with an optimization of the results 😄 ).

Results for chrome 138 are uploaded.

Due to the problems with chrome for testing we're still using the chrome desktop version.
Seems like chrome 138 is pretty good. create 10k rows seems like 10 msecs faster than before and the other benchmarks also improved a bit. Nice!

Once again I'm happy to see that variance in the results is again pretty low. The vanillajs family is in the right place.

Attached you find a binary build of all frameworks such that you can run the benchmark without installing and building all frameworks (see README for how to use the build.zip)

Results for chrome 137 are uploaded.

Due to the problems with chrome for testing we're still using the chrome desktop version.
No big changes since chrome 136 for the benchmark.

Once again I'm happy to see that variance in the results is again pretty low. The vanillajs family is in the right place.

Attached you find a binary build of all frameworks such that you can run the benchmark without installing and building all frameworks (see README for how to use the build.zip)

I decided to include only keyed frameworks in this run. Non-keyed frameworks will be included only for even chrome versions from now on (performing both runs blocks my laptop painfully long and non-keyed frameworks deserve some bashing 😄 ).

Results for chrome 136 are published.

Due to the problems with chrome for testing we're still using the chrome desktop version.
Results are once again a bit faster than for 135 (which was a bit faster than 134), mostly for create rows.

Happy to see that variance in the results is again pretty low. The vanillajs family is in the right place.

Attached you find a binary build of all frameworks such that you can run the benchmark without installing and building all frameworks (see README for how to use the build.zip)

Results for chrome 135 are published.

Due to the problems with chrome for testing we're still using the chrome desktop version.
Results are once again a bit faster than for 134. Seems like create and replace are about 0.5 msecs faster for the fastest frameworks.

Happy to see that variance in the results is again pretty low and I'm even happier that this run just worked without any issues.

Attached you find a binary build of all frameworks such that you can run the benchmark without installing and building all frameworks (see README for how to use the build.zip)

Results for chrome 134 are published.

Due to the problems with chrome for testing we used the chrome desktop version.
Results are also a bit faster than for 133. Seems like create, replace, remove and append are about 0.5 msecs faster for the fastest frameworks.

Happy to see that variance in the results is again pretty low.

Attached you find a binary build of all frameworks such that you can run the benchmark without installing and building all frameworks (see README for how to use the build.zip)

I just saw that I already grumbled that the chrome 132 run wasn't straight forward. Obviously I didn't know what expected me for chrome 133 😄 .

Some time ago I decided to switch to the chrome for testing (https://github.com/GoogleChromeLabs/chrome-for-testing#json-api-endpoints). I hoped incremental runs were better if I used a fixed chrome version without the security updates. However as it turned out there appears to be an issue with the chrome traces for chrome for testing (#1838 ). A solution would have been to restart the chrome process for each and every benchmark loop. However this creates such noisy results that make no sense to publish (and the whole benchmark run takes too long then).

Luckily the issue does not happen for the normal chrome edition. So we're back to that and I'm absolutely happy to publish the results for chrome 133: https://krausest.github.io/js-framework-benchmark/index.html

Other than that I didn't see big changes.