On Thu, 2011-06-30 at 03:36 +0200, Roland Scheidegger wrote: > Ok in fact there's a gcc bug about memcmp: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052 > In short gcc's memcmp builtin is totally lame and loses to glibc's > memcmp (including call overhead, no knowledge about alignment etc.) even > when comparing only very few bytes (and loses BIG time for lots of bytes > to compare). Oops. Well at least if the strings are the same (I'd guess > if the first byte is different it's hard to beat the gcc builtin...). > So this is really a gcc bug. The bug is quite old though with no fix in > sight apparently so might need to think about some workaround (but just > not doing the comparison doesn't look like the right idea, since > apparently it would be faster with the comparison if gcc's memcmp got > fixed).
Looking at the struct again (it's been a while), it seems like it could be rearranged to be variable-sized and on average significantly smaller: struct lp_rast_state { struct lp_jit_context jit_context; struct lp_fragment_shader_variant *variant; }; struct lp_jit_context { const float *constants; float alpha_ref_value; uint32_t stencil_ref_front, stencil_ref_back; uint8_t *blend_color; struct lp_jit_texture textures[PIPE_MAX_SAMPLERS]; }; If we moved the jit_context part behind "variant", and then hopefully note that most of those lp_jit_texture structs are not in use. That would save time on the memcmp *and* space in the binned data. It's weird this wasn't showing up in past profiling. Kieth _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev