The file listbox drawing speed in TC8

[serjayes]

First, the context: I grew up on th NC in DOS, with Windows switched to Windows Commander and still can't work on Windows without the Total Commander. I have a computer with the latest processor and Windows 7 and one that is 10 years old, running Windows XP SP3. I use always Full view.

With TC 8 I recognized a drop of speed in filling the "Full" view "listboxes" on the both panels, compared to the previous TC releases. I keep "icons / show only standard icons" settings since forever because I really want the "immediate" response of the TC.

I know that TC 8 is compiled with Lazarus and that we can't expect everything to be "exactly the same." However it seems that something in the critical loop of filling the "listboxes" got significantly slower, so much that even with only a hundred or so files in the directory on TC 8 I can recognize the process of the "listbox" being slowly filled.

Am I alone in observing this? Is there an interest in solving this "glitch"? If there is, I'd be pleased to help. I don't know the details of TC implementation, but for the software I made I know that it helps turning off visual refreshes during the bigger updates (adding more items to the "listbox" at once) and that there is a number of other possibilities to make visual updates more pleasant. Thank you.

[Horst.Epp]

I see no delay while displaying dirs with tausends of files in it.

[Sir_SiLvA]

I know that TC 8 is compiled with Lazarus

this is only true for the 64bit Version have you tried to compare 32bit and 64bit on the same machine?

[EricB]

Well,

I use Windows 7 32 bit @home and I always start TC with a fixed set of tabs. When I start TC8 I always see a significant delay in reading a tab's folder. It just freezes for a second after showing 20 or so entries (so not even a full listbox), and only then continues. I do not observe this behaviour for the same folder in TC 7.57a. The settings for TC8 are more or less inherited from TC7, so there are only minor differences.

Of course I need to do some more determined tests (starting both with a clean ini, virus detection on and off etc), but I would say that OP has a valid point here.

Regards, EricB

[ghisler(Author)]

Unfortunately I do not see any such delay. Maybe you can use a tool like "process monitor" from www.sysinternals.com (now part of Microsoft) to see what is going on during that second? Maybe TC is trying to access some inaccessible network drive or so?

[serjayes]

Unfortunately I do not see any such delay. Maybe you can use a tool like "process monitor" from www.sysinternals.com (now part of Microsoft) to see what is going on during that second? Maybe TC is trying to access some inaccessible network drive or so?

Thank you. For now please ignore this report and I'll write if I have anything new -- I closed all tabs in both 7.57 and 8 and tried to repeat this running both versions side by side and doing the same things in one then another and I can't see some really obvious difference. Deep apologies.

[EricB]

Maybe TC is trying to access some inaccessible network drive or so?

I recently installed a new (wireless) router, and when starting up my computer all network drives are marked with a red cross. At least one of my tabs has indeed a reference to a network drive, so this might be the culprit. I will investigate further.

Regards, EricB

[Corand]

Well, this issue is not solved yet. I do have the same issue of the speed the listbox is filled. With the 32 bit version this is much faster. With the 64 bit version there is a delay at first (i.e. after a PageDown key or when using the mouse scrollwheel) and then you can see it fill the listbox one by one.

[EricB]

I recently installed a new (wireless) router, and when starting up my computer all network drives are marked with a red cross. At least one of my tabs has indeed a reference to a network drive, so this might be the culprit. I will investigate further.

I also see the same behaviour on a wired connection, which does not produce redd crosses. I observed that it happens most prominently when the computer just started, so it is possible that a number of background processes is posing the delay. Of course TC is the first program to be started, so it would feel the delays

My system has some complicating factors: TC is residing in Dropbox, so it is synchronized across different locations during computer start, which might cause some delay. I'm also using junctions/symbolic links to mask the TC location, so it just appears to be a folder in the root of my data drive.

Christian, when I use Process Monitor and filter on process Totalcmd.exe, I still get a huge output results. Any hints on how to refine/filter a bit? I see lots of Buffer overflow, Name Invalid or Invalid Device Request results. And massive reads of folders, maybe because of the amount of open tabs?

Regards, EricB

[ghisler(Author)]

No, tabs are only read when they come to the foreground. Try comparing the time in the log with the time when you had the freezes (e.g. by opening the clock with seconds indicator in addition to TC).

[EricB]

Try comparing the time in the log with the time when you had the freezes (e.g. by opening the clock with seconds indicator in addition to TC).

Did just that and I found some reproducible results: both Imagine.dll (of version 1.09) and SumatraPDF.exe (latest development build) seemed to induce those freezes. The freezes are not only in the listbox itself but also the drawing of the buttonbar, drive details (next to the drive dropdown) and tabs remains grey until the freeze is over.

For Imagine.dll I see multiple Createfile/ REPARSE and QueryOpen / SUCCESS entries, then a freeze of 4 seconds and then again CreateFile followed by normal processes (and not looping). For SumatraPDF comparable behaviour.

Is this the AV interfering with the file to be accessed?
Christian, if the logging from ProcMon is of some value, I'm happy to send it to you.

Regards, EricB

[ghisler(Author)]

Try removing the Imagine and SumatraPDF plugins and check whether it gets any better.

[EricB]

It took some time, but I did various tests:
- Only disabling Imagine and sLister (which is a wrapper around SumatraPDF) still gave slow drawing
- Removing SumatraPDF altogether from my system really speeded things up
- Adding the 2.1.1 Official build of SumatraPDF (instead of the latest development build) showed some delay in drawing, but much less than before.
- Re-enabling Imagine and sLister again did not make much of a difference.

I see that my splitting up of wincmd.ini via RedirectSection also seems to render some delays in ProcMon, but this might just be the background processes taking their CPU. The drawing problems are most eminent just after startup of the PC. And all of TC is inside Dropbox and has junctions/symlinks, which might complicate matters even more....

All over it seems that it is very hard to pinpoint the problem and it is most present having just started up the computer.

I'm not sure if the NAME INVALID and BUFFER OVERFLOW results in ProcMon is something which needs to be investigated?

Regards, EricB

[ghisler(Author)]

Normally these errors should be no problem - you can checks with the time stamps whether any of these operations takes a long time.

[EricB]

Yes, I will do that, but after holidays. If I find something I'd better report it in a new thread, I guess.

I did some rearrangement of plugins and everything seems much faster now, so it just might have been a malconfigured or misbehaving plugin which slowed down things.

Regards, EricB