Same here. I want to say we are getting too many branches with the first clicks, because it is faster after that first load, but I’ve never looked at that repo.
Yeah I noticed that it slowed down.
I’ve been waiting for some major projects of @anoek to finish before talking with him about approaches to speed up.
Mirrored position handling is kind of in the maybe future, unless someone else picks that up.
1 Like
There’s prefetch and caching going on.
Maybe not-prefetching the branches from root would be a good idea.
It’s possible that thought experiments and experimentation to find some easy wins could be productive … I kind of wanted to be able to measure some stuff before optimising.
(It also could be dreadfully slow code in there - OJE back end was my “I need to learn Java Spring - never touched Java before” project)
1 Like
Mirrored position handling is kind of in the maybe future, unless someone else picks that up.
I thought Josekipedia did position mirroring, but it turns out that actually only Waltheri does that.
Yeah - I stole the principle of “add Joseki down and left” (or whatever it is) from Josekipedia, which is their approach at keeping it at least tractable, knowing where to find a sequence.
I think there’s a best of both worlds solution, but admittedly my web dev knowledge isn’t good enough to know it’s feasible.
I think two calls: a small one to get the correct node and info, and a larger one to pre-fetch children (and grand children?) nodes would give you speed on both ends.
1 Like
Yeah at the moment it fetches “the rest” along with the move that it needs.
But here’s where profiling is needed - maybe it would actually go quicker now if it did not try to prefetch at all. It depends if it’s the query for the prefetch slowing it down badly, or the sheer number of requests … or whatever…
1 Like
BTW it is currently serving one request every 2 seconds, which is not outrageously fast, but is well beyond what I had imagined it might get to within the forseeable future when I was building it…
4 Likes