[webkit-dev] Why does Frame.h use mutable members instead of OwnPtr?

[Eric Seidel]

Oh, certainly page speed wins.  I suspected such was the original
desire.  I continue to doubt their all needed.

The project continues to be paralyzed by a lack of a real public benchmark. :(

-eric

On Fri, Jun 11, 2010 at 6:23 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Jun 11, 2010, at 6:17 PM, Eric Seidel wrote:
>
>> I'm all for PLT speedups (despite it running too fast on modern
>> hardware to be useful, it's all we got).  But I'm very against
>> build-time explosion. :(
>>
>> I bet we don't need to inline all of these.  Would be nice to know which ones.
>>
>> Inlines requiring additional headers (especially for Frame.h) increase
>> the .o size of most WebCore .cpp files and increase overall build
>> time.  I need to write some sort of scripts to help us check for
>> header includes we don't need.
>
> I'd be happy to see any build time speedups that don't cause a measurable speed hit. It should be easy to find through testing whether some of these data members can be changed to smart pointers without a speed hit.
>
> Note: inlining methods that access these is still possible even if they are in separate headers, the methods just need to go into that separate header. So the main costs at issue are extra allocations and extra indirection.
>
> If it's a tradeoff between page load speed and faster compile time though, I think page load speed wins.
>
> Regards,
> Maciej
>
>