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.
No comments:
Post a Comment