When entering a folder in a file panel or Tracker view, I can see the files populating in the view as the Tracker “notices” them. It usually takes probably about 1-200 ms for a folder with 50-60 files in it. At first it was kind of a neat effect, but now I’m starting to wonder what is it DOING all that time? “ls” can spit out the same folder’s contents instantly; it seems like GUI listings should open almost equally fast. I know PoseView is in the process of being refactored; is this something that’s being looked into? I can’t see any reason why there should need to be a visible delay just to load folder contents.
If this is because of loading icons or attributes, couldn’t it put all the filenames in their place immediately, then do the “population” effect on whatever part of the file entry it is that is slow?
I think that yes it is a bit slow (even though it is faster than you are used to).
If you look at a REALLY big folder and try to list its contents with ‘ls’ and with ‘find’ in turn and it could take minutes for the former to provide an output. Those two commands take different approaches to spitting out results. The difference is that one streams and the other collates and presents.
In short, no I do not know the answer to your question but thats for food for thought.
I looked at PoseView once, years and years ago, and it really is (at least was) a complete mess. It’s probably one of the few remaining bits of code from Be Inc. itself (pretty sure it hasn’t been refactored since the first OpenTracker release) and it seems to mix together all the code for displaying the window and getting all of the file information.
I don’t know the exact reason for the poor performance, but looking at process controller when opening a large folder in tracker shows the app_server doing a lot of work. If I remember correctly from my brief glance at the pose view code, every time the window is notified of a file it will do a view update. For list views this involves a screen-to-screen blit to make room for the new file (copying everything below the new insertion point one line below) and then invalidating the new area. Not sure Haiku does screen-to-screen blits (because everything is double buffered) so that probably is not the neat speed-up trick which it was on BeOS. Obviously a much better approach would be to batch up new notifications over a small-ish period (200ms or so) and then only redraw the view that often - this would still make Tracker appear responsive but would lose the majority of the overhead of those thousands of view redraws.
There are quite a few factors involved including suboptimal drawing (which was a problem on BeOS as well, PoseView was just as slow there, if not moreso since OpenTracker did make several improvements to population speed), as well as some poorly chosen/scaling data structures. These are known issues and are being worked on in a development branch. It’s unfortunately not as simple as update batching since the app_server does this already on its side.
anevilyak - good to hear someone is working on it! I remembered after submitting my post that the app_server did batch up calls, but there is also obviously some overhead associated with the calls anyway as they involve interprocess communication. Still it may well be that the main problem lies elsewhere.
