well our caching routines should cache the files in the way minimax described.
If it is being cached in each time, then something else might be wrong.
To be honest I never used dosbox with more then 1000 files in one directory.

MiniMax :

Sadly this dosnt work. (I get the "SHELL redirect output to NUL")

But it still takes an age to load.

As I said above it takes the same amount of time to read the folder every time.

IE you can go into it once, then come out then back in and it will still take time to read the folder. (About 8 seconds to read a folder with 200 items)

Qbix : Im currently useing a dir with 200 - 300, this still takes about 8 seconds.

I can give you access to the software setup to try if you are game.

Thanks,

I hopefully have some time to work on dosbox this evening.
Not sure if I make it to your problem then. (got some patches to review)

You might want to see what happends if you enter dir inside the same directory twice.
(does the time decrease then ?)

I can go into it again and again and again but it stays around the 6 - 8 seconds mark.

It may get a FRACTION faster after the first couple of times, but this may be my counting.

If you have time to try - www.ukln.co.uk/visicaddosbox.rar

Is the APP + Dosbox im using.

Extract to C:\
Edit "CONFIG.DAT" in C:\VISICAD - Everywhere it says "I:\" change that to a mapped network drive you have.
In the mapped network drive you have make a folder called "workf" and fill it with 200 - 300 random small files.
Run the extracted short-cut

Once your in the app :
Main Program
Press enter on the Demo messege
Type any inital and press enter
Then press tab - Here is where you wait ........

Thanks,

Has anybody had any time / luck with the above yet?

okay there is 2 times the same path in there. so that doubles the amount of time (workf is read 2 times totally by the application)

I don’t follow you?

In the dosbox config? or the software itself?

And I don’t understand if it was caching wouldn’t it only takes a long time once then after that be pretty fast?

psynox, well I'm checking our caching algoritm currently.
but I noticed that the application reads i:\workf\*.* twice, probably because it is stored twice in the CONFIG.DAT file.
So you could lower the loading times by changing one of those 2 path to an empty directory. ( as workaround for the problem)

I don’t think it reads it twice?

I:\workf; This stores global work files
I:\workf; This stores local work files

The CONFIG.DAT just holds the locations it calls up, so when you press tab to brows the folder its only going to load it the once / one of the lines?

And I still don’t understand why when you have gone in once after that it should be instant as it should be cached already?

well I checked the code of dosbox.
Our caching of the directory lists works fine.
the application reads it twice (because of the 2 lines?)
Basicly when you press tab the application reads first
i:\workf (takes 10 seconds or so)
then it reads
i:\workf again (which takes 10 second).

The contents of the directories are cached. however the individual files (their date and time and size isn't)
with 1200 files this is what takes most of the time. I think it this took the same amount of time on a normal pc as well. aside from that fact that that one was probably faster (in cpu terms) compared to dosbox.

The only thing we can do to improve this is actually cache even more. (the dates and size of each file)

I'll look a bit futher. maybe one of our routines is very slow. but I could create a test application which does the same lookup as dosbox does on all files in a directory to see if that produces the same results ( timewise).
the we would be certain that the looking up of the date and time of each file is the slow operation.

You might want to run with fixed cycles(10000 or so) instead of auto cycles as all those file operation will probably mess up the cycle guessing code.

I just removed the "I:\workf; This stores global work files" line from the CFG, and it took exactly the same amount of time.

(I’m currently testing with 200 files, this takes 10 seconds)

So it’s not reading both lines that’s the problem / doubling the time.

cycles=10000 also has no effect

The time it takes doesn’t seem to scale in the way you would think either.

IE if its 10 seconds for 200 files 700 files should be 35 seconds, but in reality it only takes 20.

Monday morning here again,

And updates reguarding this problem?

I have the same problem with access to network drives that are mounted. I was wondering if a patch was ever made to cache the date, time, and size of each file. The cad program that I am using display each and it causes the directory to list very slow.

I tried using LBACache from FREEDOS but it seems that the drive are emulated in a way that LBACache can not pick them up. It would be cool to use LBACache because then the user could activate the cache only if they need it.

Me thinks that if your users are insisting on using this old software... then placing these files into reasonable subdirectories shouldn't be that much to ask of them.

However - I've never actually run DOSBox against anything on a network (other than mounting a CD image off a network drive). I might download your example and play around as well.

I dunno if this is related, but i'll report it anyway: i'm using a self-made menu system inside DOSBox, based on 4DOS and some batch files. All my games are on a networked drive (Windows 2003 server, 100MBit network), which i use like one big "c:"-drive. My batch generates an index file by doing something like "dir meta*.txt /s >index.txt" (not sure about the correct syntax), and afterwards processes the generated file line by line to build a menu. The "dir" part takes forever on my system, and i always had the impression that DOSBox is reading the dirs slower than it should. I have about 150 directories to scan through, and it takes about 5 to 6 minutes for the "dir" command to complete. Switching cycles and core settings has little effect. Maybe this is an area where DOSBox could use some optimization, though i'm not sure how useful that would be for "general gaming" operation.

EDIT: forgot, i'm using vanilla DOSBox 0.72 or ykhwong's build.

I'm sure optimization could be done but I don't think optimizations should be done.....

It's the same thing as using PST's over a network, Outlook is trying to access the .PST as if it was local thereby chewing up massive amounts of bandwith.....

Are you just using regular Windows shares or have you tried NFS or iSCSI?

Ah, you're no newbie, so i don't have to be friendly (; Just kidding (there's another thread going on)

Anyways, nope, didn't try anything else yet. I'd like to have a gigabit ethernet, but lack the resources to buy the hardware ATM (several NICs, switch, etc.). iSCSI is more for connecting dedicated hardware, like streamers and stuff, isn't it? I do have a large PST file on the same server the games are on, but honestly, i don't think this is a large performance hit. I didn't do any precise measurements, but in the Windows system monitor, i can't see any bandwith being used by just having the PST open in Outlook (i do most of the "mail work" on an IMAP server, though - the PST is for archiving purposes). What you are writing about Outlook chewing up bandwith sounds like one of those "Windows is evil"-myths one hears so much (; . I'm pretty sure the building of index files, as described above, will take roughly the same amount of time, no matter if Oulook is accessing the PST, or not.

To go on ranting: i _hate_ NFS, though i'm not quite sure why. It just seems so anachronical (?) to me. I've tried it once, but it's not really an option - maybe if the server was running Linux.

Optimization - no matter in which field - should be done once major bugs are fixed, and the devs have free time on their hands, IMHO. I'll always appreciate a little speed increase. (;

Well bandwidth is more of a concern when you have multiple users with huge .PST's.

The issue is more of how Outlook was programmed to handle .PST's:

http://support.microsoft.com/kb/297019

Interesting link! I thought that'd only apply to older Outlook versions, but the article says otherwise. Looks like a clever strategy to get companies to switch over to Exchange Server (; . Anyways, it's just one user on my home network, so i don't think this issue is critical.

Concerning "optimization", there may be a misunderstanding: i'm not talking about optimizing DOSBox for access over mapped network drives (that would be too specific and useless IMHO), but maybe optimizing the way DOSBox accesses files and directories in general.