Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Albedo]

Just an idle late-night thought - anyone tried this?

I don't have nearly the RAM necessary, but I'd think someone would.  Anyone ever go there?

[DeathOfRats]

Hmm, I haven't tried it myself, but I might have to give it a whirl later, just for scientific curiosity.

My hypothesis is that it won't matter much, since most of the low-fps causing things are computation related (e.g., path-finding) and not disk-access related.

I'm guessing it might speed up the seasonal auto-save, though.

[PencilinHand]

Hmm, I wonder.

DF isn't that big storage wise but it does occupy a curiously large amount of memory(~225 mb in fortress mode) for something so small(maybe 40 mb on the HDD for the game and one large map save).  I suspect that everything DF needs is already being put into memory when it loads so it shouldn't need to access the HDD much if at all during actual play.  Hence, I doubt there will be any appreciable gain in performance through a virtual drive as the only advantage a virtual drive has comes from reducing the time a processor spends idling while waiting for the HDD to retrieve data.  Saving/loading on the virtual drive will improve, though.

The only real improvements to performance are going to come from revising the code for more expedient run-time operation(either by offloading stuff from the CPU like the ongoing graphics update and/or by writing the code smarter) and from significantly improved processor technology/speed(massively expanded processor cache should help).

[Albedo]

First time I ever tried it was for Doom - turned all the graphics options up to max, and WOW - it was hummin', and you could see every thread on every screw in every explosion.

But DF certainly doesn't have "graphics generation" as a bottleneck, or at least not much.

Like I said, mainly just an idle, late night thought.  Keep us posted if you do try it!

[DeathOfRats]

Well, I've been poking around at the ramdisk idea, which turns out to be a pain in the rear to do in windows xp, apparently. It's a pity my linux system in this laptop won't run DF (or any other SDL applications) due to a problem with the graphics driver 

So, anyway, I managed to make a small ramdisk of 32 MB (the little bugger would stop working if I made it any bigger), which was enough to run DF, and loaded my latest fortress. It's in the middle of a megaproject construction (I'll post about it when done ), has a pop of 58 little buggers, and runs at about 30-40 FPS normally (probably because there's a reeeeeeally long aqueduct which is on its way to be filled).

There's no detectable improvement from using the ramdisk, since with it it still hovers at around 30-40 fps (since the FPS display goes up and down pretty much every frame, I don't know if I might be gaining one or two fps *shrugs*).

Pretty much what I expected: since DF does use a lot of memory for such a small program, it's already keeping all it's data in memory, instead of reading it from disk.

Strangely, there's not as much of an improvement as I expected when saving data. This might indicate that a lot of the time spent for saving is spent somehow processing the data into a saveable form, rather than writing to disk - this could be consistent with save game sizes. It's, what, 6MB for a save? That's not a lot of data to write to disk, nowadays, so it shouldn't be taking as long as it if that's the only thing it did.

[Puck]

Could have told you guys right away that disk access time isn't the thing that slows DF down 

Cheap version to find out: listen to your harddrive while playing. If it aint shoveling data like mad, it wont get any faster from using a ramdisk 

[DeathOfRats]

Could have told you guys right away that disk access time isn't the thing that slows DF down 

I was pretty certain of that, but it never hurts to check just in case 

[Kadath]

If anybody want to try, the command in linux to create a ramdrive is:

mount -t tmpfs tmpfs /name/of/directory

Then move df_linux into that directory. By default, it's half of the system ram in size, and only uses up as much ram as needed - ie an empty folder uses no ram.