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?
Glad to know it works for someone / error is most likely on my side.
Are you referring to dev tools → performance tab → record
or the Incr_dom thingy that writes to dev console and has options for toggling debugging / profiling / … ?
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.)
Thanks. 1 more question as I dive into profiling this:
What version of the code did you run ?
- unmodified v0.15.1
- unmodified master
- modified master
?
#1 builds for me; #2 did not build for me; I’m running #3 where some
Node.blah attrs:[ ... ] because Node.blah attr:( ...)
Thanks!
Unmodified v0.15.1 (cloned from that v0.15.1 commit). Well, unmodified except for adjusting the number of rows in app.ml.
Btw, if you’re going to look at profiling, you might find this github issue interesting as well.
1 Like
I’m not sure if I am using the chrome profiling tool properly. I am getting:
Summary:
20269 ms
15 ms Scripting
2 ms Rendering
0 ms Painting
23 ms System
20231 ms Idle
20269 ms Total
Bottom Up
14.6 ms88.8 % Major GC
1.1 ms6.7 % 1.1 ms6.7 % Hit Test
0.4 ms2.6 % 0.4 ms2.6 % Pre-Paint
0.2 ms1.4 % 0.3 ms1.7 % LatencyInfo.Flow
0.0 ms0.3 % 0.1 ms0.5 % Commit
0.0 ms0.2 % 0.0 ms0.2 % Event: mouseover
0.0 ms0.0 % 0.0 ms0.0 % Layerize
Call Tree
14.6 ms88.8 % Major GC
1.1 ms6.4 % 1.1 ms6.4 % Hit Test
0.4 ms2.6 % 0.4 ms2.6 % Pre-Paint
0.2 ms1.4 % 0.3 ms1.7 % LatencyInfo.Flow
0.0 ms0.3 % 0.1 ms0.5 % Commit
0.0 ms0.0 % 0.0 ms0.0 %Layerize
Event Log:
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
side note
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
The good news it that Incr_dom code itself is doing very little work? Bad news is: why are we generating some much GC ?
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.
I think I was doing something incorrect with the performance capture last time (possibly due to iframes, not sure). Here is a capture of a more simplified app running ts_gui
I am wondering if this has something to do with it.
If I try to run unmodified virtual-dom v0.15.1, I get an error of:
296f39-da20-4737-b988-862385f861c7:2528 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'Symbol')
This appears to be due to:,
if (this.Symbol) {
hook_state_key = Symbol(hook_state_key);
}
changing that line to if (this && this.Symbol) { ... fixes it; but I wonder if (1) this is a symptom of an error somewhere else and (2) this may be causing excessive diffing / updating.
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?
That’s interesting…I’m definitely running the virtual-dom through opam v0.15.1.
What’s with the filenames in your profile btw…are you running some sort of bundler or something on the generated js_of_ocaml output?
-
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’).
1 Like
Here you go.
^ I’m almost positive I read something about this somewhere, but I can’t remember where, sorry.
-
Thanks for the repo.
Dealing with {joo_tramp, joo_args} - #6 by hhugo ? This might be a related issue.
1 Like
I have no idea how I went this long without checking this, but here’s our problem: appears no partial rendering taking place.
-
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.
Huh that is interesting.
I’m pretty sure that the row height is calculated here with the bounding rectangle. Not sure if that would be connected to the css thing you mention though…