Announcement for Users Concerning EDF Performance

If you are having problems with the performance of the EDF parser (ie, the game pauses at the "Processing EDF file..." message for more than a second), I have discovered an easy solution.

The overhead is due to the zone heap now being too small by default, causing stress on the memory allocation functions. Because this also impacts performance during play, I recommend this for all users.

To fix the problem, use the "-heapsize" command-line parameter, or set the heap size option in the Eternity frontend on the System / Debug options tab. Provide a value of 16 or greater, and you will see marked improvement in performance.

Command-line Example:

eternity -heapsize 16

The next version of Eternity will use a 16 MB heap by default, more than likely, so this will not be permanently necessary. EDF has pushed the average minimum dynamic allocation amount over the critical 8 MB mark, so it's time to graduate up.

You might want to note, Quasar, that using -heapsize 16 will require more memory. I've found that Eternity runs fine with -heapsize 16 under Win98SE on a machine with 48MB of memory, but it might not run as well on a machine with 32MB or less.

Valid point. You'll want more than 32 MB RAM before you use that, I'm pretty sure. I doubt Windows can deal very well with an application asking for half the system RAM. Everyone can try it out, and if the game seems slower, or just plain fails to start up, they shouldn't use it.

BTW, even if I increase the default heap to 16 MB, you'll still be able to manually force it to 8 MB (which is the minimum allowed anyways). I doubt there'll be much use for doing that though ^_^

Ah great, this fixed the mega-lag I was getting in maps loaded with EDF-based obstacles :D

auxois said:

You might want to note, Quasar, that using -heapsize 16 will require more memory. I've found that Eternity runs fine with -heapsize 16 under Win98SE on a machine with 48MB of memory, but it might not run as well on a machine with 32MB or less.

Don't forget that Windows has a virtual memory management. You can allocate as much memory as you want but as long as you don't actually read/write from/to it there isn't actually any real memory being used. Of course this only applies if the zone heap isn't initialized to some predefined value upon startup.

Of course on modern OS's a construct like Doom's zone heap doesn't make much sense anymore anyway so if it wasn't such a major amount of work to remove it I'd say to get rid of it altogether.

Yeah, like I said in #zdoom, if I weren't targetting as broad a number of operating systems as possible (although only two are officially supported right now, I'd like to expand that, and it is easy to do so with SDL), I would go ahead and replace the zone system with a Win32 virtual memory map. But, since the zone system needs to stay around for other operating systems, and IS in some respects still more efficient due to its ability to provide domain-specific allocation lifetimes, the memory map code would be redundant.

Come to think of it, it would still be nice if the zonebase could at least be allocated using one of those under Windows, but AFAIK, the zone algorithms aren't programmed to be able to handle a zonebase of dynamic size. I can check into this though ;)