|
From: Serge v. d. B. <sv...@st...> - 2002-12-30 23:45:02
|
On Mon, 30 Dec 2002 ms...@mo... wrote: > The following patch silences a small batch of warnings about > comparison always true/false in src/sc2code/libs/memory/w_memlib.c. > [...] > MEM_HANDLE should probably be an unsigned short, and then all of the > h > 0 tests would have to be nuked... since negative values don't > appear to be used, this would double the number of chunks available. Line 392: extents[i].handle = -1; extents[i].handle is of type MEM_HANDLE. > pps: > since the extents array is static and 20 bytes per element this patch > lowers the runtime memory usage of the program by about 1.3 Megs. That's considerable. > I've not done any tests to see how small the array can safely be sized... It would need some extensive testing in various game circumstances. I do assume there's a reason the array is this large to start with. (though the memlib was originally supposed to be seperate from star control itself, so it could have been a precaution, or because of another game. > but would be willing to write code to dynamically increase the size of the > extent array as it is needed, so that it can be started very very small > and grow. I'd need to know this would be desired by whoever controls > memlib... There's no-one in particular in control of the memlib. But I'm not really satisfied with the thing in its entirety for our purposes. It seems to do pretty much what malloc itself does, and malloc probably does a better job at it too. It could be a big speed-win too to rewrite the thing to do just basically malloc(), as - when using threads - malloc is thread-safe by itself, so there's no need for the extra locking that memlib does. Serge |