200-300 ms intervals of gc are very disruptive when interacting with plots in GLMakie, for example. It would be much better if GC ran more often but only for 5ms or so at a time so that the chance of dropping frames is lower. I have no idea if something like that would be feasible, but I see these kinds of delays as a big blocker for all kinds of uses that Julia could in principle have, where real time interaction is needed and longer pauses do not lead to “failures” (as in hard real time scenarios like controlling a plane or so), but are just very annoying and deteriorate the user experience a lot.
2 Likes
It might be reasonable to insert soje manual GC.gc() calls into interactive use, so they happen at times that are good.
I Wonder if there is a way to say “maybe do GC here if you feel like it”
2 Likes
@jules, do you have an MWE so we can add it to list of things that the GC could do better at?
Not really special ones, like when you interact with an Axis in GLMakie, it has to compute new ticks etc and that all necessarily allocates. So you get a lot of these jerks when using the package because you’re usually dropping multiple frames when gc runs.
Right, but can you reproduce that with a simpleish script or does one need a full application/interactivity.
I wonder if we did something like GC.gc() on the MouseDown event.
So that you can hold and drag sliders, and it might have a little jitter at the start but when scrolling back and forth would be smooth.
Maybe with a check to Dates.Libc.TimeVal() to prevent it from gc’ing too often. So repeated clicking also doesn’t stutter
(Test.LibC.TimeVal runs in under 20ns where as Dates.now() takes 100 cos it constructs julia times structs)
Maybe GC.safepoint(), or GC.gc(false)?