ggaren at apple.com
Thu Aug 27 16:44:37 PDT 2009
> What about functionality where the C API would slow down the C++ API
> but the
> internal JSC API is stable enough/good enough?
If there are such areas, and they turn out to be substantial, we
should look at speeding them up, for the benefit of all clients of the
> I can think of the debugger for example.
Actually, the debugger is an area that has caused substantial problems
during our optimization work. It exposed too much internal engine
knowledge, so it was hard to keep it working as the internals changed.
Also, since our various debuggers weren't covered by our standard
regression tests, we often broken them without knowing.
I think it's very hard to know, a priori, what will and will not be
efficiently supportable going forward. Personally, I've been very
surprised more than once. The advantage of the C API is that we've
already signed up to support it. So, if the Qt API piggy-backs on the
C API, we'll support the Qt API implicitly, and our regression tests
will verify, for the most part, that the Qt API still works.
If the Qt API introduces new internal dependencies, we may break it
without knowing. Moreover, the performance trade-offs involved may
argue for not fixing it.
More information about the webkit-dev