Tag-Folder Tree-Rename a subfolder: 100% CPU usage

[hopalongrock]

The little rename window remains on the screen, the rename is successful as I see later, but I have to close TGF because of the never ending 100% CPU usage.
This happens with my main folder, containing ~4600 subfolders (album).
There is no problem when I rename a subfolder in a folder containing only a few subfolders.

This occurs too, when I rename a subfolder out of TGF, and refresh the folder containing it in TGF.

From these I think, the refresh causes this in TGF.

[jtclipper]

Do you have auto-scan enabled?

[hopalongrock]

Do you have auto-scan enabled?

Yes, I always enable it.
But there is no difference, if I disable auto scan, and make a rename.

I forgot to mention, that at first there is a little disk activity (1-5 sec), but later during the 100% CPU there is no disk activity at all,

[jtclipper]

I suspect it's the tree-view control iterating and rebuilding its structure, one more question do you have the folder expanded or not?

[hopalongrock]

I suspect it's the tree-view control iterating and rebuilding its structure

Probably. But when at the first time I click on my folder (containing ~4600 sub-folders) to expand it, the elapsed expanding time is about 1 - 1.5 min, the CPU usage is about 40-50 %, and there is big disk activity.
When I rename, there is a very short disk activity (probably the rename itself), the CPU goes to 100% without disk activity - I wait more than 5 minutes before closing it. If TGF rereads the structure of the folder above the deleted subfolder, I think it should do it with the same method as initially, probably with a refresh.
But the elapsed time (TGF seems to be on loop), the 100 % CPU usage and the missing disk activity suggest me that TGF makes another thing.

, one more question do you have the folder expanded or not?

I don't really understand your question - the folder is expanded, I right click on the subfolder to rename it. The subfolder only contains files, I see the files because of the autoscan.

[hopalongrock]

I've just finished a series of tests: The rename of 1 sub folder from
580 sub folder is 31 sec
680 sub folder is 42 sec
900 sub folder is 1 min 07 sec
4630 sub folder is 28 min -- finishes, but very slowly (quadratic growth ??)

If I stop and restart TGF, the full folder read time ~14 sec (probably because of cache),
when I start TGF at first time, it's 1 min 15 sec.

Maybe you can speed up the refresh after the rename or make a full re-read.

For now I think I will exit from TGF, make the renaming, and restart TGF.

[jtclipper]

I've had a look and its all in the component used for the directory tree, the way it is using API calls to read back the data after a refresh and how the OS itself servers that data back.
In short too many folders on a single container are slowing things down considerably , I am sure windows explorer handles that much more efficiently and i would have either to change the component used or fix the code, both of which are rather low priority.

[hopalongrock]

OK, thanks.