Page 1 of 1

Extremely slow startup (solved - for me at least)

PostPosted: Sat Oct 13, 2012 8:31 am
by The Underdoug
Hi all,

For any of you that have encountered an issue with BRU taking an inordinate amount of time to startup (1 minute to half-an-hour or more), I have tracked down my own issue to some exceptionally large (>10GB) zip files residing at the root of the drive that I was starting up BRU in. By moving these super-large archives to a new dump subfolder (just below the root), this startup time goes to sub 1 second. It appears that, despite saving the last folder used and starting BRU using the explorer context menu whilst pointing to the folder in question, BRU goes to the root of the drive where the folder in question resides and, if there are zip files, scans inside them for a folder structure (can be very slow). I suspect that this is a windows rather than a BRU thing (unless, unbeknownst to myself BRU has zip scanning ability). If BRU is using the windows calls to access the directory, it appears that windows lists the directory structure at each level of the path to find the next level. For zip files at root directory level, it appears that folders within the zip file are indexed as if they were a flattened hierarchy at root level.

My apologies if my spiel above has confused terminology used by linux bods. I am talking in strictly windows terms here.

Re: Extremely slow startup (solved - for me at least)

PostPosted: Fri Jan 31, 2014 8:30 pm
by djtk
Program worked fine on initial launch by installer, but all subsequent launches left the program window blank for as long as I was willing to wait, about 2 minutes. The window title block said "Not responding".

Solved the problem by adding the usual target directory as a parameter to the program name in the program icon properties/target, which now reads:
"C:\Program Files\Bulk Rename Utility\Bulk Rename Utility.exe" C:\Users\djtk\Documents

In spite of the unusually busy interface, I quickly found the function I wanted and was pleased to see the immediate preview of the result. Great work!

Re: Extremely slow startup (solved - for me at least)

PostPosted: Tue Mar 01, 2016 7:03 am
by glachancecm
This bug is back or was never solved. Easy to see what happens with process monitor (sysinternals). I remember making a similar post a couple years back but I could not find my account from back then. I think it was banned - no idea why... I'm a nice guy and don't talk shit on forums.

The slow loading is caused by the program reading all the zip and cab files in every folder leading to bru's current folder. So if you launch in E:\A\B\, the program starts up, then goes and reads all the zip files - byte per byte - in E:\*.zip and E:\*.cab, then it does the same with all the files in E:\A\*.zip (and E:\A\*.cab) and then again in E:\A\B\*.zip (i'm actually not sure about this last one - it may not do it).

Sidenote: it does not read 7z files.

Obviously, removing those files makes the loading process almost instantaneous.

Re: Extremely slow startup (solved - for me at least)

PostPosted: Wed Mar 02, 2016 12:13 am
by Admin
Thanks, that is great analysis. We will try to replicate and fix the problem. I guess BRU is currently trying to treat zip files as standard folders and reading their content but it should not. thanks

Re: Extremely slow startup (solved - for me at least)

PostPosted: Thu Mar 17, 2016 2:34 pm
by glachancecm
Found it!

I got the big arsenal out (procmon, windbg, app verifier, and depends) and found the culprit. Somehow one of the components in your app is triggering window's own zip file shell extension (zipfldr.dll). It the same one that, in explorer, allows you to extract files with the context menu and puts the extra options in the explorer toolbar. It's been around since vista i think? - and is still in w10.

Anyway, as soon as I disabled it, bru went from loading in around 2 minutes to instantly.

So, to reproduce:
- put a (big) zip file in C:\, in C:\A\ and C:\A\B. Make bru's current folder C:\A\B. close BRU
- Start BRU. (You will notice very slow start (depending on how many zips/cabs and their size)).

If you want to disable the shell extension, you cannot disable it with regsrv32, ==> follow instructions here : disable-windows-built-in-zip

By the way, I would bet a whole lot of money that the component that is triggering the shell extension is the treeview or one of it's dependant. Maybe the component you use for the context menu inside bru?

Anyway, this is as much info as I can find without a pdb, I hope this is helpful.

thank you for making bru free for personal use.