AsyncWB no longer asynchronous

[xenic]

@tbreeden

Same machine environment here, similar results. Dragging the TBImages directory to either a FAT formatted or a SFS formatted USB stick seems to work about the same. Workbench is fairly usable (on other devices) during the copy. Sometimes the copy seems to hang up for 5 or 10 secs during which WB is not responsive, and sometimes a click on a WB icon seems to be missed. Maybe the root of the problem is not AsyncWB.

I think the problem was more apparent to me because I was testing with a USB mem stick that turns out to be less than half as fast as my other USB mem sticks. I blamed AsyncWB because I also tested with the C:Copy command & Dopus4 and copying the same TBImages directory had no effect on WorkBench input response that I could detect. However, both C:Copy and Dopus4 have problems with links so I use WorkBench copies for large copies and backups. Maybe the problem has something to do with the fact that AsyncWB is updating a WorkBench window (progress window) while it is copying? Speaking of C:Copy, I really wish they would fix it to handle links as well as AsyncWB does. If the OS and SDK installers are going to create links, we should have an Amiga shell command that handles them properly.

[xenic]

@tbreeden

The real problem with directories like TBImages, with 3000+ files, is that they are almost unmanageable via WB. Opening TBImages with view-by-name does usually complete, but takes 20 to 30 seconds to show anything, during which WB is unusable. And if you make the mistake of opening a directory like that with view-by-icon+all-files, you are sunk. At least I was never able to do that just now - WB and Dock unusable, the Clock Docky stops, eventually the pointer and keyboard seem frozen (I suspect the USB driver is not reacting well to this situation). Waited 20 minutes or so and nothing completed.

I discovered that the TBImages size was a problem a long time ago. I was trying to find out why a small program was taking so long to load. I discovered that it was a huge delay caused by loading images from TBImages on a slow FFS partition. I tried to draw attention to the problem in several posts to Amiga forums. I even emailed the AISS author asking him to devide TBImages into subdirectories before his AISS project became too widely used to change. Unfortunately, nobody was willing to listen to me and AISS is so well established that it can't be changed. It currently contains 5000 files but could grow to 10,000 or more eventually. We wouldn't have sub-directories (drawers) if putting all files in one giant directory or volume was fast and effecient. Oops. Sorry about the offtopic rant.

[cha05e90]

I discovered that the TBImages size was a problem a long time ago.

It might be solvable through multi-assigns...

[tonyw]

If you must depend on third-party add-ons like AISS, then you should have them on something other than the system partition. In this case there is no reason to store them on a slow old FFS system partition, you could have them on a fast JXFS or SFS partition.

However, I think that the slowdown here is caused by the massstorage transfer. Some USB sticks (especially cheap ones) are actually only USB1 internally, making the problem worse. Is the CPU activity particularly high during this transfer?