My BSP loading code was taking 30 seconds plus in a debug build, but loaded almost instantly in a release build. Turns out that BSP loading requires over 6000 allocations, because of my use of STL vectors without a custom allocator (Something I'll deal with later). In debug builds, it uses my memory manager, which performs a stack walk to find where the allocation came from. Unfortunately, when the allocation happened, I did a full stack walk; which involved going through each stack frame, walking up one function, getting the function name, checking if it starts with "PMemory::", "operator new" or "std::", if it doesn't then it's probably the caller. That's pretty slow, mainly because of looking up the function name.
So, the new code just walks the stack for up to 16 frames, and records the program counter (the EIP register in x86, RIP in x64). Then it does the symbol lookup, and finds the caller when it dumps any memory leaks. So that takes about 2 or 3 seconds, which is much better, and acceptable for a debug build.
Without the stack tracing code (But still using my memory manager), it loads in about half a second. The stack trace code can be turned on or off with a preprocessor define in the memory manager header, which isn't included by a lot of files, so it's easy to do.
Also, I found that non-power of 2 textures are A Bad Thing. The graphics card in my server (ATI X300) objects to them. It doesn't crash or spit out any warnings, even with the debug D3D runtimes, it just uses the top left texel over the entire texture. The reason being, it supports np2 textures, but conditionally. The D3D docs say that "conditionally" supporting np2 textures means that the textures can't repeat, so the wrap mode needs to be "clamp". In Quake BSP files, the texture coordinates pretty much equal the vertex coordinates, so you might have a square with texture coords of (15365, 47365), (15366, 47365), (15365, 47366), (15366, 47366). And that would be bad for non-wrapping textures.
I've now added a couple of functions to my engine to check for np2 and non-square texture texture support (Might as well go all the way...). I now need to stretch the original texture to a power-of-2 size if needed, and then use that. Which is a bit of a pain, but it really needs done for older cards like this. I don't want to support non-vertex shader cards, but non-non-power-of-2 textures is reasonable.
Anyway, my friend is back now...
