Hi Eric,
first I tried to install the exe within a 700 MB ramdrive created with
rdisk.
Extracting it needed in about 47 minutes instead of 58 minutes.
Then I zipped the folder with all 4.018 files with FD zip within a few
minutes (ca.4min).
Then I run the FD unzip command over the original watcom.exe file and it
also needed only in about 4 minutes to extract everything (all files and
folders were extracted). But the installation routine for config /
autoexec is missing, so it is not the optimum. Additional comments see
below.
> Hi Willi,
>
>> I downloaded open-watcom-2_0-c-dos.exe (an extracting .exe) at:
>> https://github.com/open-watcom/open-watcom-v2/releases/tag/Current-build
>> 140 MB size.
>
> This is a self-extracting ZIP file. You can try using our
> build of infozip UNZIP to extract it. Maybe the downloaded
> exe uses build settings which are not fast for DOS or which
> expect more than 32 MB RAM. Maybe it even uses a swapfile?
>
> As reported I used 256 MB RAM at the end of my yesterday test. No real change
> in speed.
> Unzipping the watcom.exe file with FD unzip works fast.
>
> I also expect that extracting 4000 files in DOS, some of
> the directories containing 100s of files (samples/clibexam,
> h/nt, binw, binnt, ...) to be slow without a decent cache
> and generally slow because our caches do not write-combine.
>
> If you had 500 MB RAM, you could extract to a RAMDISK ;-)
>
> I did, see above. Result: yes, but not really fast.
>
> I agree that it is frustrating when the self-extractor
> takes 58 minutes in FreeDOS and less than 1 in Windows,
> or less than 5 in the DOS 7.1 of Win95 or Win98.
>
> I only tried to reproduce a reported "bug" to confirm if the report is corret.
>
> You say that when you added RAM or a cache, you saw circa
> 20% progress after 10 minutes, but I am not sure whether
> you aborted the experiments at that point or whether the
> extraction crashed at that point instead of completing in
> a total of 50 minutes?
>
> I had no fun to wait more 2 x in about 40 minutes, so I stopped
> the test. No crash.
>
> You could test how long it takes to extract the files
> in Windows and then boot FreeDOS and use either COPY or
> XCOPY, with or without a cache, to copy it. I remember
> a thread where I suggested an XCOPY patch to pre-allocate
> all clusters before incrementally copying file contents,
> in order to avoid frequent incremental FAT updates, but
> I do not remember whether pre-compiled XCOPY binaries
> with this patch are available. It may improve speed :-)
>
> Copying all 4000 extracted files from C: to ramdrive - or back - (with dn2)
> worked in three or four minutes.
>
> All 4000 files in the self-extracting ZIP use ZIP version
> 2 compatible DEFLATE compression, so the problem does NOT
> seem to be a too fancy compression, which would need more
> RAM or optimizations for newer CPU etc. I guess the REAL
> problem is FreeDOS being slow in file and metadata writes.
>
> I have no real idea if it is a read or write problem. I personally think it
> may be a read problem with finding the position
>
> of the files to extract in such a big file (140 MB). Do you know a tool where
> I can create a big .exe file working in DOS?
>
> I am sure we have had threads about this before, even
> with people testing kernel patches to aid performance,
> maybe somebody remembers something specific about that?
>
> Regards, Eric
>
> Cheers, Willi
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
