Re: profiling XEmacs, esp. on the C level

JR> Ok, in that case I'll have to rework the whole scheme JR> significantly. Does this mean I can stick to optimizing the two-bit JR> case, or will we need to support a different number of bits soon? Marcus> It will stay two bits for the new garbage collector, one bit Marcus> for the old one. Optimizing both cases would be nice, but what Marcus> we really need in the long run is the two-bit case. Ok, I'll special-case the 1 and 2-bit scenarios. That's going to be a lot of #ifdefs, though. Marcus> What about porting your optimizations to 64 bit platforms? Marcus> Would your changes be of any use there? Yes, definitely, but on these architectures it's probably better to process mark bits 64 at a time, or at least retrieve them that way. The mulinv division algorithm will not work, as it relies on 32 bit wraparound, and I'd need to extend it to work on 64bits. The other thing is that someone would need to do quite a bit of benchmarking, I don't know how expensive integer division is on current 64-bit platforms. It might turn out that it isn't that bad at all. --J.