> Thanks for update!
You are welcome! This update was difficult, VERY frustrating and it took
me 5 days to get a proper solution. But, nice results -- UIDE speed has
improved, and I did NOT need my "emergency plan", which was to put UIDE's
search tables back into normal memory! UIDE still takes only 4864 bytes
of upper-memory, or 992 plus 3824 bytes of HMA space, for any size cache!
> In this opportunity I would like to ask what is now the more important
> part of speed benefit what UIDE gives. It is the caching or the DMA
> transfers? From your changelog it seems like DMA is more or less
> obsolete. Or am I wrong?
Both DMA and caching are important, but in different ways.
I tried UIDE with caching but with my hard-disk run by my BIOS, and I set
the BIOS "VDS services" flag, so the BIOS would not use DMA. 32 seconds
to copy my big WINNT\SYSTEM32 directory, v.s. 5 seconds when UIDE handles
the disk using its own DMA routines.
If I use UIDEJR, i.e. DMA but no caching, copying my WINNT\SYSTEM32 files
takes 13 seconds, v.s. 5 seconds as above.
My conclusion: If one does much file copying, DMA is more important, but
if one does much "repetitive" reading of the same files (compilers, data-
bases, etc.) caching shall obviously become more important.
As I note in the drivers' README file, the best plan is to load RDISK and
put heavily-used files in RAMdisk memory, then load UIDE and let it cache
"ordinary" data files. RDISK uses 752 upper-memory bytes, UIDE uses the
memory noted above, plus the XMS memory needed for both drivers. Rather
a "cheap price", for their HUGE improvement in DOS performance! ---
(Account disabled on user's request.) |
Thread view
Board view
