VOGONS


Slow load from network map ?

Topic actions

Reply 23 of 38, by chmichael

User metadata
Rank Newbie
Rank
Newbie

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)

Reply 24 of 38, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 26 of 38, by chmichael

User metadata
Rank Newbie
Rank
Newbie

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

Attachments

  • Filename
    dosbox-map-drive.zip
    File size
    542.29 KiB
    Downloads
    481 downloads
    File license
    Fair use/fair dealing exception

Reply 27 of 38, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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).

Reply 28 of 38, by davek

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 29 of 38, by headbngr

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 30 of 38, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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).

Reply 31 of 38, by headbngr

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 34 of 38, by ADDiCT

User metadata
Rank Oldbie
Rank
Oldbie

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.

Last edited by ADDiCT on 2009-02-18, 12:25. Edited 1 time in total.

Reply 35 of 38, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Water flows down the stream
How to ask questions the smart way!

Reply 37 of 38, by ADDiCT

User metadata
Rank Oldbie
Rank
Oldbie

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. (;