i debugged that specific application and most of the time spend was actually inside the emulated program
not in dosbox generating the listings. (but this was without network,but with a lot of files)

The only thing that dosbox does that slows it down is a stat call on each file to determine the date and time of the file.
That might be slow on a networked drive, but I don't see an other way to get valid date and times in the directory listings

It would be nice if the client OS could cache the information locally. Then it would be up to the client application to either

1) Request a cache update before accessing the information, or

2) Set a flag in the stat() call indicating if an possible out-of-date/cached status would be acceptable.

I just did a quick test on my own in DOSBox by mounting a network drive I have (mounted in OS X, hosted on a Linux server via Samba) and running "dir" on a directory with 3600 zip files for DOS games. The processor usage for DOSBox stayed pegged until the directory listing comes back. Now for kicks I tried running an "ls -l" on the same directory from the OS X terminal and it took even longer, though it used far less processor power. Now I could see where the argument for caching might come into play - but truth be told I'm not sure it's such a great idea. If this data needs to be cached, then it's the job of your OS to do so. Beyond that, you have no way of having meaningful caching unless you have some way of knowing when something has changed. Based on what we are talking about here... it seems that there is no way to do that without incurring the very same performance penalty that the caching is supposed to be rid of in the first place and adding some more memory bloat in the process.

I think caching the file names is a great idea (which DOSBox already does hence the "rescan" command). Caching file sizes, dates and times is less than useful however.

Yeah It's probably the fact that it is networked that is too blame. Maybe modern oses are slower then old dos based networks

Dark - you said the share was mounted via Samba. I would be interested to know if it made any difference if you mounted it as an NFS share with the async and noatime options turned on.

http://developer.apple.com/DOCUMENTATION/Darw … doc/man/8/mount

darkgamorck wrote:

Now I could see where the argument for caching might come into play - but truth be told I'm not sure it's such a great idea. If this data needs to be cached, then it's the job of your OS to do so. Beyond that, you have no way of having meaningful caching unless you have some way of knowing when something has changed.

This might be true but this is also the same for the names. If the names are cached and the file gets deleted other than inside DosBox, DosBox will still show the file existing. So what is the big deal if the dates and sizes are not updated. Whenever the file is opened DosBox will refresh the data anyway.

darkgamorck wrote:

I think caching the file names is a great idea (which DOSBox already does hence the "rescan" command). Caching file sizes, dates and times is less than useful however.

It is if you are using a program that shows the date and size of the files. This means DosBox needs to fetch the data every time because the dates and sizes are not cached.