On Sun, Dec 01, 2013 at 09:47:06PM +0000, Michael Drake wrote: > > I've just made a fairly significant optimisation to libcss's selection > engine performance. It's now using more memory, but hopefully that's > worth the extra speed. Please let me know how you get on with it. Cool. A couple of things concern me about this change:
1) The presence of a bloom filter internal to libcss is leaked through the API to the client. This doesn't permit us to change the libcss implementation details without clients' knowledge. 2) Related to the above, the change to the css_select_style is a backwards-incompatible API/ABI change. We've strived very hard to avoid this in the past. Is there any reason why: a) the bloom details can't be hidden entirely within libcss? b) libcss can't generate the bloom for a node, rather than relying on the client to do so, which is fragile if the bloom size is changed within libcss and the client is built against old headers? c) we can't extend the libcss selection callback table to permit libcss to store information on a dom node? (The selection callback table is versioned, so libcss will have to fall back to the old, slower, behaviour if it's called from a client built against the old version) J.
