On 15/10/2007, Luke J Crook <[EMAIL PROTECTED]> wrote: > Brad Beveridge writes: > > > All functions that should really be non-consing & very quick, and > > probably inline too. I think that R, G, B, A functions are slow due > > to the way that Lispbuilder stores color as a vector, rather than a > > (simple-array (unsigned-byte 8)), though it maybe should even be an > > (unsigned-byte 32). > > I couldn't work out why FP was consing/slow, I assume that is an SBCL > > problem with auto generated CLOS reader functions. > > > > Anyhow, I don't know if anybody cares :) > > I care. I started looking into this a couple of weeks ago, after I profiled > one of the random rectangle examples over a 90 minute period and found that > it CONS'ed several hundred gigabytes of RAM. What makes things worse is that > a function can be called ~60 times a second, so any small amount CONSing > really starts to add up after a few seconds. > > Does anyone have any experience in CL optimization? I don't have any, but I expect that reducing consing (at least for speed == 3 builds) is a good start. I normally turn speed up to 3 & read SBCL's notes. Some of the stuff I mentioned could be fixed with some minor changes to the code, but I think it is a little hard in places due to the current design. Some random thoughts: - Color is a 32bit number, but the layers in Lispbuilder hide that fact. The data is stored natively as a vector, which has type (simple-array t (*)). If anything it should have type (simple-array (unsigned-byte 8) 4). Or - IMHO better still - it should be stored as (unsigned-byte 32) and R,G,B and A will directly access that member. Then pack-color basically becomes a slot access. - Some of the consing comes from small functions having to box up a return value, FP is I think one of these functions. If FP were a normal function, I'd just say inline it. However, it is a method & may be too large to really inline, which means we are stuck with boxing up the foreign pointer. I don't see an easy way to solve this - I like the FP function being a generic function. Maybe FP can become a macro that expands to (slot-value obj 'foreign-pointer-to-*). This is one of those situations where I like C++'s object model a bit better :) I don't know, maybe declaring the type of the object would be sufficient to get the compiler to choose the right dispatch case & inline it?
Cheers, Brad _______________________________________________ application-builder mailing list [email protected] http://www.lispniks.com/mailman/listinfo/application-builder
