There shouldn't be any performance costs. Instead of returning a
boolean (as the virtual function call does today), it will return a
constant AtomicString which can be compared to another AtomicString in
one instruction.
Adam
On Wed, Oct 19, 2011 at 1:31 PM, Sam Weinig wrote:
> I'd be interest
I'd be interested in performance cost to that, especially on a test that
creates a lot of JS wrapped Events.
-Sam
On Oct 18, 2011, at 6:42 PM, Adam Barth wrote:
> My thought on that is to use a single virtual function and return an atomic
> string, like we do for elements.
>
> Adam
> On Oct 1
My thought on that is to use a single virtual function and return an atomic
string, like we do for elements.
Adam
On Oct 18, 2011 6:10 PM, "Sam Weinig" wrote:
> For the specific case of Event, we do need some sort of poor man's RTTI
> here for the sake of the bindings, but we could consider alt
For the specific case of Event, we do need some sort of poor man's RTTI here
for the sake of the bindings, but we could consider alternatives. Since you
need to identify the subclasses, you need to either use many virtual functions,
as we do currently for Event, or have some tagging mechanism,
Related:
Reducing sprawling includes, particularly in headers, can have a large
effect on incremental build times (and thus developer happiness).
Tightening layering practices between WebCore and WebCore/platform
also paves the way for splitting out platform into a separate .a, also
decreasing inc
The other day, Sam chided me on a bug for including a header from
WebCore proper in a file in WebCore/platform. Even though I know I'm
not supposed to do that, it's an easy mistake to make. There's some
work going on in https://bugs.webkit.org/show_bug.cgi?id=49192 to
improve the style checker to
6 matches
Mail list logo
