2009-12-03, 01:50 PM
I tried it on a larger patch:
GMS 0.73 --> 0.78 (228MB)
I tried out a new method that would hopefully get a middle ground between reading everything in memory and not. I figured that much of the slowdown is also caused by consistently freeing and malloc'ing memory. So instead of doing that, I used a cached memory and just read into that. If I needed more, I allocated more, but I kept the same memory throughout. This means that the memory usage is nowhere near as high as the fastest alternative, but it's still relatively low. I think it's a good balance between the two.
ENTIRE FILE NOT READ INTO MEMORY: 3m 35s
ENTIRE FILE READ INTO MEMORY: 2m 10s
A lot of the slowdown here was from unpacking the patch data, though, which took up 40s on both of these trials. I think increasing the cache utilized for zlib unpacking will make it quicker without utilizing much more memory.
GMS 0.73 --> 0.78 (228MB)
I tried out a new method that would hopefully get a middle ground between reading everything in memory and not. I figured that much of the slowdown is also caused by consistently freeing and malloc'ing memory. So instead of doing that, I used a cached memory and just read into that. If I needed more, I allocated more, but I kept the same memory throughout. This means that the memory usage is nowhere near as high as the fastest alternative, but it's still relatively low. I think it's a good balance between the two.
ENTIRE FILE NOT READ INTO MEMORY: 3m 35s
ENTIRE FILE READ INTO MEMORY: 2m 10s
A lot of the slowdown here was from unpacking the patch data, though, which took up 40s on both of these trials. I think increasing the cache utilized for zlib unpacking will make it quicker without utilizing much more memory.