LHA 2.15 stopping at 'unable to open file'

[asrael22]

256MB compressed to 99MB.
Didn't take the time. Will do again. Currently in operation...

I wasn't at the computer when it finished, but it was well under an hour.


Manfred

[asrael22]

Hmm, that's interesting. Actually I've looked for some options and have seen -b option.
But I didn't try it because I thought that I/O buffer only sets the general read/write buffer for the files. The documentation does not mention that this setting helps with lots of input files to complete at all. So I'm a little surprised.

Anyway, this setting has helped.
Thanks a lot.


Manfred

Even more curiously, setting a 64k buffer (-b64) doesn't work either.

[awol2k]

I wasn't at the computer when it finished, but it was well under an hour.
Manfred

Before I went to sleep, I decided to run a comparison againts 7zip on the i5-3320m Windows 7 laptop I was running that WinUAE on.

To compress the same 231MB of data I did using LhA, i used 7z archive format with ultra compression, 64MB dictionary size and 2 out of 4 available CPUs*

It took 2 minutes and 9 seconds.
While it was running, it used 699 MB of RAM - this amount of ram did not fluctuate - and despite the settings in effect it used all 4 cpu cores to perform the archive process.

Now, the way LhA archives appears to be different.
This archives 1 file at a time into temp and THEN appends the data for that one file only to the LhA file it has created. If the data it is reading from is store on disk, this typically has a big overhead on an amiga. If the LhA file it is writing to is tored on disk, this has a massive overhead on an amiga.

So for a comparison i'm going to repeat the process in RAM: alone.

Edit @ 14:59, 15:01:
WinUAE is reading from DH0: (a windows folder) at approx 500 KBps. This is one heck of a bottleneck.