3/06/2004

03-06-04 - 1

03-06-04

If you're managing a tech group and one of your programmers shows you the "cool project" they've been working on at home, tell them "that's nice", and *walk away*. By no means put it in your code base! It's hard to resist when someone shows you something that's "already working" and cool and has a sexy demo. But resist you must! Just because it's working in a demo doesn't mean it will work in a real production pipeline, or that it is bug-free, low in memory use & CPU use, etc. etc., in fact the whole technique may fall apart when stressed (eg. PSM, Stencil Shadows). BTW, I used to be the *worst* offender ever for this type of practice. At Eclipse and Wild Tangent I would work my ass off late and night and on the weekends and come up with crazy crap, and then show it to management and get it snuck into the code base. It was a lot of fun, but it certainly was not the best way to serve the engine. On the plus side, I got to learn Terrain LOD, VIPM, curved surfaces, etc. etc. none of which were really needed for the engine. If I were managing the old me, I would tell old me that it was great stuff, and keep up the learning process, but keep that shite the hell away from my code base. And if you do sneak it into my code base and then tell me "it's already in", I'll tell you to get it the fuck out and don't sneak it in without asking me ever again.

The proper way to make a profiler (for CPU use and Memory use) is as a "two-way" hierarchical view. That is, you have a normal hierarchy with 100% usage at the root, then you can see his kids, and all the kids add up to the parent value, etc. Then, you can also go backwards. For any element, you can grab that element and switch to a backwards view, where you instead see the sum for that element across all parents, and you see a tree going backwards to the parents, so that leaves are at the top and the parents are at the bottom. Let me try to show an example, cuz that writing is really unclear. Say you have a normal tree like this :

A-{ B,  C }
    |   |
    |   +-{D, E}
    +-{C, D}
Then the backwards (multi-root) tree would be :
C - {B , A }
     |
     +-A
D - {B, C }
        |
        +-A
E - C - A
Each node of the tree should be sorted by the biggest offender. The key to being a really fluid profiler is the ability to switch on the fly between the forward tree and the backward tree; you need to be able to select any element and switch between forward and backward tree views.

No comments:

old rants