GetBidiProperty large part of time inside nsTextFrame::ContentChanged To be exact: 41542 21 92 nsTextFrame::ContentChanged 31 nsFrame::GetBidiProperty 22 nsBlockFrame::ReflowDirtyChild 7 FrameManager::GetFrameProperty 6 PresShell::GetFrameManager 2 nsBlockFrame::FindLineFor 2 __i686.get_pc_thunk.bx 1 nsBlockFrame::MarkLineDirty So of the 92 hits under nsTextFrame::ContentChanged something like 54 are involved in getting the property. Is the property possibly set on any frame? Could we test for the NS_FRAME_IS_BIDI flag on the current frame to see whether we need to bother with the property? Or is that flag about something else?

source is from helping someone in #mozillazine. The number of iterations (|seconds|) starts at around 7 million right now.

Oh, and it will take a while (10 minutes or more on my 1.6GHz pentium) to run to completion--don't run it unless you are prepared for that. It's probably a good idea to divide seconds by 10 or so before running it.

>Could we test for the NS_FRAME_IS_BIDI flag on the current frame to see whether >we need to bother with the property? Or is that flag about something else? That should be OK. We do exactly that in nsTextFrame::GetChildFrameContainingOffset() and nsTextFrame::MeasureText()

So... would it make sense to just do that check in GetBidiProperty so callers don't have to worry? Or do bidi properties get set on frames without the NS_FRAME_IS_BIDI flag? Could we at least add a IsBidiEnabled check (off the prescontext) in the latter case (like some parts of nsTextFrame do)? It'd be nice if this flag and the various properties were usefully documented or something.... and ideally, it would be good if GetBidiProperty knew which props it's safe to just bail for if NS_FRAME_IS_BIDI is not set....

I'll take this.

I suppose it makes sense to fix bug 117751 before this.

If we plan to, sure. ;)

THe patch in bug 117751 makes the testcase ~5% faster by wallclock.

When I say "the testcase" I mean this version of the testcase in attachment 138789 [details].