yeah I expect that to make a difference.

If it does (do you have a testcase, too?) we could try to get rid of it (FindFirst
windows function returns the attribute for example, which we don't use
at the moment).

wd:
Then go to drive_cache.cpp, function CreateEntry() there is an if clause

No improvement ... 🙁

Qbix:
seriously ? I designed the LOG()() class so that they should be optimized out in release mode. At least that happened last time I checked the compiled code (compiled with mingw though)

Yes, but a litlle bit ...

Since it's around 1000 files it call LOG for each file ... (And i think you're logging 2 times in drive_cache.cpp)

Yes but only when you got the debugger enabled.

No improvement ...

I don't see any possibly-slow operations that could be omitted, though you
might want to add some timing code or so to specific functions.

wd:

I'm using the "Release" version ... i don't use the debugger at all.
I'm investigating drive_local.cpp now and i'll try the LOG_MSG() with timing ...

Ok, I used process monitor to identify what Dosbox does ...

You can download process monitor at:
http://technet.microsoft.com/en-us/sysinterna … s/bb896645.aspx

1) Download and Run process monitor
2) Stop and Clear the capture
3) Open the attached log file

Notes:
As you can see it does QueryDirectory every time the application opens the file!!! and it does the same things 4 times ...

Any hints ?

Thank you

every time the application opens the file!!!

I was assuming you are talking about mounting or DIR*.*ing being slow.
Is it only that application that is slow, and if so what does the app do that
it has to *open* every file of a 1000+ files directory (which sounds stupid).

I was refered here from another thread as I appear to be having the same problem trying to use dosbox with an application at work. My original message is below.

**

I hope I will not upset the network gods (and goddesses) asking this question here with my non-existent network skills.

I am a user of CAPing software at work. This, conversationally, makes G-code programs for machine tools to run. The CAP software, of course, is an older dos package, is a gazillion dollars to update, and won't run under XP. And of course, they need to run all computers on XP now.

Our IS department got it running with Dosbox and the megabuild. Needed the megabuild to have the software access a dongle. It runs surprisingly well. with one fatal problem.

They are running the software from our network, and say they must. It loads up quickly, runs OK, but seems to have some problems with some access.

When you are paging through screens of program filenames, there is a distinct lag when paging down. The really big problem though, is that when you start a new program there is a lockup of a minute or so. When it is starting a new file it takes forever. If you start that new file in a directory with just a few filenames (ridiculously few) it does OK.

I've been trying to separate our thousands of files into sub, and sub-sub-sub directories, but it is just too cumbersome. If there is any way you all could help me help our network guys get this going, I would greatly appreciate it. They are about to give up and the next step is third-party software which. I feel, would be inferior.

Save me from genera-CAP!

**

I understand that dosbox was written to play dos games but it is also finding a home running older design and manufacturing software. Many times this is software that was made for the specific machine or process and anything newer would be inferior, maybe even not work. This CAPing software is still a very powerful application and I would love to keep using it. Any help would have me singing dosbox's praises for sure.

chmichael wrote:

Notes:
As you can see it does QueryDirectory every time the application opens the file!!! and it does the same things 4 times ...

This might be the way your application is written. I have a similar CAD program that does the same thing. I think it is because the files names, date, size, and proprieties are not cached in dosbox. So what happens the program first queries the file names, then dates, then size, and finally the attributes. Thus the reason it queries the directory 4 times. This is why the only way to fix this type of problem is to write caching into DosBox. You will always have this problem with older dos programs written to query file information. Almost all DOS games have no use for the file information hence it has no been a priory for DosBox.

If you have caching, you need to react on external events to keep the cached
data up to date, which will be MUCH slower (especially over a slow network)
than grabbing the actual data as-needed and relying on the caching system
of the underlying layers (OS file/drive cache, network caching if it exists).

wd wrote:

If you have caching, you need to react on external events to keep the cached data up to date, which will be MUCH slower (especia […]
Show full quote

If you have caching, you need to react on external events to keep the cached
data up to date, which will be MUCH slower (especially over a slow network)
than grabbing the actual data as-needed and relying on the caching system
of the underlying layers (OS file/drive cache, network caching if it exists).

Would it be possible to keep a simple cache method where it caches the data for a small time then purge the cache after a few secs. I think this would speed up programs that query multiple times for the same data.

Filenames are already cached, and up to now nobody has told what dos call
really is the issue (like get file attributes calls for each file, or even open calls).

Anybody who could do some testing? (speed checks, compatibility etc. whatever he likes)

Well, what do you need tested? All i can say now (without any intensive testing) is that DOSBox "feels" slow when running from a mapped network drive. Just for fun, i've coded a 4DOS batch that builds a menu based on metadata files in the game diretories. All this batch does it to recurse all dirs in a certain path (network drive), read a small text file and parse it. There are about 150 game dirs, and maybe 20 or 30 "non-game-dirs". The whole process takes ages, and "feels" very, very slow - much slower than i'd expect it to be. I've already tried various core/cycles settings, but these do not affect the speed very much.

I'm not sure if this really is an issue. I mean, my use case is not so common, i think ("emulating" a large DOS hd instead of just mounting one dir per game). I can live with the waiting time, though i think performance could be better. The devs should decide whether this is a "real" issue or not. I could do some testing if i'd know what to test, or what to look for.

it's a nice example test case. Won't gain much from the sort removals, but the stat thing might influence it.

Yes i expect the stat() to be comparably slow on those network drives for whatever reason.

Just tell me if you need more data. I could try to adapt my batch to run in the Windows versions of the JPSoft utilities, which would give us some values for comparison. But i'd rather not do that if the possibility of having this issue (or non-issue) fixed is very low. (;

I need a few different scenarios (yours sounds like one of them) to test a few
stages of changes to the directory structure caching in dosbox.