Layout efficiency / Freeze/Thaw updates?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Layout efficiency / Freeze/Thaw updates?

clahey@clahey.net
Hi.  I write an application called Democracy.  On linux, we're using
gtkmozembed to display a major portion of our UI.  We're experiencing
slowdowns on UI updates.

Specifically, for a UI update, we remove a dom element and insert a new
element in its place.  Sometimes this takes 0.002s and we're very happy
to have hundreds of elements get replaced.  Unfortunately, sometimes
this takes .2s and we have serious slow downs.

I haven't figured out what the difference between these two cases is,
but I suspect that in the slower cases we're redoing layout of the
display for every element we change (so I suppose twice per update,
once for removal and once for add.)

My question is how to fix this.  My guess is that I might be able to
tell gecko/gtkmozembed that I'm going to be doing a whole bunch of
updates, do the updates, and then tell gecko that I'm done.  So my real
question is: Where do I find an API to help me coalesce updates?  Do
you think this is what's causing the slow downs we're seeing?

Thanks much,
     Chris

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Layout efficiency / Freeze/Thaw updates?

Boris Zbarsky
[hidden email] wrote:
> My question is how to fix this.  My guess is that I might be able to
> tell gecko/gtkmozembed that I'm going to be doing a whole bunch of
> updates, do the updates, and then tell gecko that I'm done.

nsIDocument has an API for this (BeginUpdate/EndUpdate)....  It's not frozen or
anything, but maybe it'll help a little bit in your case.

> Do you think this is what's causing the slow downs we're seeing?

Not very likely.  A lot of the things that BeginUpdate/EndUpdate actually
coalesce are coalesced even without them (e.g. layout, style changes, etc).  As
long as your application is not using CSS quotes or counters,
BeginUpdate/EndUpdate won't help you that much.

Is there a consistent piece of code that's being slow?  If so, I'd be interested
in seeing it (and how it differs from the non-slow code).

-Boris
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Layout efficiency / Freeze/Thaw updates?

clahey@clahey.net
Boris Zbarsky wrote:
> [hidden email] wrote:
> > My question is how to fix this.  My guess is that I might be able to
> > tell gecko/gtkmozembed that I'm going to be doing a whole bunch of
> > updates, do the updates, and then tell gecko that I'm done.
>
> nsIDocument has an API for this (BeginUpdate/EndUpdate)....  It's not frozen or
> anything, but maybe it'll help a little bit in your case.

I'll try this.

> > Do you think this is what's causing the slow downs we're seeing?
>
> Not very likely.  A lot of the things that BeginUpdate/EndUpdate actually
> coalesce are coalesced even without them (e.g. layout, style changes, etc).  As
> long as your application is not using CSS quotes or counters,
> BeginUpdate/EndUpdate won't help you that much.

Yeah, I thought so, but maybe somehow the coalesced items are getting
unspooled by something I'm doing?

> Is there a consistent piece of code that's being slow?  If so, I'd be interested
> in seeing it (and how it differs from the non-slow code).

Yeah, that's the weird thing.  It's the same code but some race
condition differs.  I don't know what the difference is in the
different timings.

The function we're having trouble with should be near here (assuming
there haven't been too many edits.)  We call this function over and
over and over again from python.

https://develop.participatoryculture.org/projects/democracy/browser/trunk/tv/platform/gtk-x11/frontend_implementation/MozillaBrowserXPCOM.cc#L137

Thanks for the info.  I'll try BeginUpdate/EndUpdate.

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Layout efficiency / Freeze/Thaw updates?

Boris Zbarsky
[hidden email] wrote:
> Yeah, I thought so, but maybe somehow the coalesced items are getting
> unspooled by something I'm doing?

That's possible in general, yes.

> https://develop.participatoryculture.org/projects/democracy/browser/trunk/tv/platform/gtk-x11/frontend_implementation/MozillaBrowserXPCOM.cc#L137

Nothing obvious jumps out at me in there (other than that maybe you want to use
ReplaceChild)....

-Boris
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Layout efficiency / Freeze/Thaw updates?

clahey@clahey.net

Boris Zbarsky wrote:
> [hidden email] wrote:
> > Yeah, I thought so, but maybe somehow the coalesced items are getting
> > unspooled by something I'm doing?
>
> That's possible in general, yes.

So, I've looked at the timing information again.  I was wrong.  It's
not taking .2s for each item.  It's now taking .004-0.020s for most
items and sometimes taking 1.004-1.020 seconds for a single item and
going back to the smaller numbers.  It's very weird that it's always
exactly an extra second.  There's one instance of it taking .249
seconds, but mostly it's very close to 0 or 1.

> Nothing obvious jumps out at me in there (other than that maybe you want to use
> ReplaceChild)....

Unfortunately, ReplaceChild isn't available on my box, so I'm going to
assume there are others who don't have it.

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Layout efficiency / Freeze/Thaw updates?

clahey@clahey.net

[hidden email] wrote:

> Boris Zbarsky wrote:
> > [hidden email] wrote:
> > > Yeah, I thought so, but maybe somehow the coalesced items are getting
> > > unspooled by something I'm doing?
> >
> > That's possible in general, yes.
>
> So, I've looked at the timing information again.  I was wrong.  It's
> not taking .2s for each item.  It's now taking .004-0.020s for most
> items and sometimes taking 1.004-1.020 seconds for a single item and
> going back to the smaller numbers.  It's very weird that it's always
> exactly an extra second.  There's one instance of it taking .249
> seconds, but mostly it's very close to 0 or 1.

Oh yeah, and beginUpdate/endUpdate doesn't seem to make a difference.

> > Nothing obvious jumps out at me in there (other than that maybe you want to use
> > ReplaceChild)....
>
> Unfortunately, ReplaceChild isn't available on my box, so I'm going to
> assume there are others who don't have it.

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Layout efficiency / Freeze/Thaw updates?

Boris Zbarsky
In reply to this post by clahey@clahey.net
[hidden email] wrote:
> Unfortunately, ReplaceChild isn't available on my box, so I'm going to
> assume there are others who don't have it.

Er....  It's part of the W3C DOM, has been for years, and we've supported it for
years.  I'm not sure what you mean by "isn't available".

-Boris
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Layout efficiency / Freeze/Thaw updates?

clahey@clahey.net

Boris Zbarsky wrote:
> [hidden email] wrote:
> > Unfortunately, ReplaceChild isn't available on my box, so I'm going to
> > assume there are others who don't have it.
>
> Er....  It's part of the W3C DOM, has been for years, and we've supported it for
> years.  I'm not sure what you mean by "isn't available".
>
> -Boris

Ah, that would be because I misread the compiler error message.  It
said there was no matching method.  I'm used to C and python where that
means it doesn't exist.  Not that you gave the wrong arguments.

ReplaceChild simplifies the code a bunch, but the timing results are
still exactly the same.

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Layout efficiency / Freeze/Thaw updates?

clahey@clahey.net
Sorry about that mistake with ReplaceChild.

ReplaceChild and BeginUpdate/EndUpdate don't seem to have helped, so I
guess I'll have to look at other stuff.

The next thing to try is for me to do some profiling of what's going on
inside of mozilla?  Is there a framework for this?

Thanks for the answers so far.  It's good to know what does and doesn't
work,
      Chris

[hidden email] wrote:

> Boris Zbarsky wrote:
> > [hidden email] wrote:
> > > Unfortunately, ReplaceChild isn't available on my box, so I'm going to
> > > assume there are others who don't have it.
> >
> > Er....  It's part of the W3C DOM, has been for years, and we've supported it for
> > years.  I'm not sure what you mean by "isn't available".
> >
> > -Boris
>
> Ah, that would be because I misread the compiler error message.  It
> said there was no matching method.  I'm used to C and python where that
> means it doesn't exist.  Not that you gave the wrong arguments.
>
> ReplaceChild simplifies the code a bunch, but the timing results are
> still exactly the same.

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Layout efficiency / Freeze/Thaw updates?

Boris Zbarsky
[hidden email] wrote:
> The next thing to try is for me to do some profiling of what's going on
> inside of mozilla?  Is there a framework for this?

If you're on Linux, then you can try using jprof.  See
<http://lxr.mozilla.org/mozilla/source/tools/jprof/README.html>.  On more recent
linuxes you could also try sysprof.

On http://www.mozilla.org/performance/tools.html there are some profilers
listed.  Not sure how up-to-date this is.

-Boris
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout