This turns out to be very smooth at 100 rows, useable at 1000 rows, and laggy at 10_000 rows. It appears the iissue is: despite the constant # of output rows, there is some internal O(# of rows) step that is causing the problems.
Hmm that is strange…I remembered running that example and it was pretty snappy, so I just gave it another shot at running it. I bumped up the number of rows to 100,000 and even when sorting the the data on last_fill which essentially causes constant shuffling of row positions it is still responsive. (Tried it on both firefox and chrome.)
Did you try profiling it with the browser devtools?
The built in browser profiler. Just a thought…You might find something weird there. (If you didn’t build with dune’s --profile=release you can even click through to the ml functions from the profile results.)
8315.9 ms 5.9 ms 5.9 ms Major GC
8940.9 ms 4.7 ms 4.7 ms Major GC
9555.5 ms 3.9 ms 3.9 ms Major GC
20212.6 ms 0.1 ms 0.1 ms LatencyInfo.Flow
3857.0 ms 0.1 ms 0.1 ms LatencyInfo.Flow
3857.3 ms 0.0 ms 0.1 ms Commit
4104.2 ms 0.1 ms 0.1 ms Hit Test
4032.2 ms 0.1 ms 0.1 ms
I have had to install both virtual-dom and incr-dom and incr-dom-partial-render from github, then go to version 0.15.1 . opam virutal-dom + incr-dom-example/ts-gui runs into some “Ojs” problem
Hmm that is actually quite different from what the profile looks like when I run it (with 100,000 rows and just clicking around and using the arrows to jump around the table). About half the time is spent in this function.
In about ~15,000 ms there is ~8700ms scripting time, with far less GC time as what you’re showing…weird. Probably worth opening up an issue about it.
I’m going go hold off on reporting this. I could not use virtual-dom / incr_dom from opam, and had to manually get them from github. I suspect the problem is my side.
Could you dump the list of all opam packages (with their versions) you were using when 10_000 and 100_000 were running smoothly from you? [and also specify any you had to install from github] ? I want to “binary search” our installs.
Sure. Check out this gist. You can searched for “pinned” in that file to see which of the packages were pinned.
I did install all the packages related to bonai/incremental/incr_dom from opam though. I did run the ts_gui example as its own separate project. Same dune file as the one on github example, but with added (modes js) clause. (I don’t know if maybe that is part of the difference.)
What happened that you couldn’t use the opam libraries? Were you using the examples code from the master/main branch rather than a release?
One more thing, can you post a tgz of your ts_gui directory? Thanks!
One difference I’ve discovered is that you are on jsoo 5.1.1; I am on jsoo 5.2.0. However, yesterday, I tried jsoo 5.1.1 too; same performance issue.
Because of the virtual-dom issue, if (this.Symbol) → (if this && this.Symbol) in hooks.js; I need to use my main fork of virtual-dom. incr_dom however wants to pull in system virtual-dom; so I have to drop icnr_dom into local project too; as well as bonsai. Basically I’m running virtual-dom, incr_dom, bonsai from local dune project instead of opam.
I’m using “git checkout tags/v0.15.1 -b local_0.15.1” on all those git repos.
Examples are from v0.15.1.
Funky file names are data URLs.
I’ve also noticed that on my local system, if I run jsoo 5.2.0 with --enable effects, none of the incr_dom examples work for me. (Not even ‘hello world’).
I got it working. @mooreryan thank you for your patience.
There is something deeply unsatisfying:
2a: I copied cloned a fresh incr_dom_partial_render v0.15.1; I copied over example from incr_dom v0.15.1 ==> still did not work, was rendering 10_000 rows
2b: then I copied over the index.html (which contains a bunch of css) instead of using my own loader ==> everything suddenly works
I have a theory that the OCaml code is somehow relying on css tags to calculate the height of the table / decide how many rows to render and that if I don’t copy the right css, the demo breaks and it renders all rows of the table instead of just the visible ones?
If the above is correct, my core problem was that I thought all the core logic was in the *.ml files; but the *.ml logic somehow depends on particular css tags in the index.html.