....
So I'm curious about this: does the current Max Buffer setting still function, or is that now ignored by your enhanced logic?
Currently it's only honored when you set it bigger than 16MByte. And only for the first file block which is copied. If the file is bigger than 16MB (or your setting) then the buffer may be increased when copying one block takes less than 40ms. And the buffer size gets decreased when copying a block takes more than 350ms. Actually the 'ideal' copy buffer size calculation is a bit more complex but the idea is to change the buffer size dynamically so that copying one block takes between about 40 - 350ms. This all has a big impact on real big files (lot of 100MBytes) and fast devices (f.i. SSDs or fast HDDs).
Originally the 'ideal' buffer size was calculated for a block transfer time of 4s (if I understand the code correct) but limited to your setting in the options and a rather small initial setting. I had to change that cause some overflow in the calculation leads to wrong buffer size and very slow transfer rates in some cases. Moreover I think most users didn't even find the setting in the options (like myself) and so the got only low transfer rates even with very fast devices.
With my current algorithm I have about 85MBytes/s when writing to HDDs and >140MBytes/s on some SSD. This is close enough to the limit my system is able to handle and I think most I can get out of a PM copy program with progress indication.
I mainly tried to optimize copy speed with big files and reals disks within the system. I've not seen a negative impact in copy speed for small files. Limited testing was done on different LAN or USB devices and different file systems (JFS, HPFS, FAT, FAT32) too without negative side effect. Unfortunately I've currently no chance to test fast USB3 devices. They do not work well on my system in general. So test result with different settings are welcome. Mind you always can compare speed with copy done from cli. Usually copy from cli is still faster. But not that much anymore than before.
...
OK, so I do have a 'feature request': WHEN looking at the contents of a ZIP file do you think you might be able to enable object recognition and the use of system-wide settings instead of the default editor that's defined in LCMD settings?
...
I consider the vfs implementation (zip file handling) in LCMD as a proof of concept. Only basic functionality is implemented AFAIK. As you already have observed functionality is very limited. I never used this feature by myself. I find even file managers which implement such feature much better (TotalCommander on Win) as rather useless and I don't use it. Cause even there it never works nearly as good as a real Archive program manager (WinRar, 7-zip, Win folder zip integration, ...). I don't see any real chance for me to implement zip/rar/arj/tar/iso/... file handling in LCMD to an extend I by myself would call it nearly useful. Not even if I got fired by my company and could work full time on this ;-). So until no one else could invest a lot of time in this part of LCMD I would suggest setting 'System launch Zip's by default'.