Closed Bug 169247 Opened 22 years ago Closed 15 years ago

Investigate allocating gecko events (nsIRunnable impls) using a recycler


(Core :: DOM: UI Events & Focus Handling, defect)

Not set





(Reporter: peterlubczynski-bugs, Unassigned)



(Keywords: perf)

from bug 132759:

Avoiding unneeded malloc's
The patches I have seen so far put all Flash messages on the PLEvent queue. This 
causes us to use a malloc'd class to hold the event info. In general I prefer to 
avoid malloc'ing when not necessary. For Flash messages which are projected to 
come in at 120 messages per second per Flash area I really would strongly prefer 
not to malloc. For example, the page today has 9 Flash animations
which if there were 120 messages per second would mean 1080 malloc's per second. 
I believe that to avoid malloc'ing for every message we  will need to test for 
starvation locally and only defer the message when starvation is happening.
Perhaps we can reuse the PLEvent starvation logic locally.

"Avoiding unneeded malloc's"

this is probably an issue for Mozilla timers as well since they are implemented
as a separate thread which posts a PL_Event when the timer expires. DHTML
animations often have at least one timer and some have many timers running
simultaneously. Maybe we need to create an arena for PL_Events?

This bug is being opened to investigate if using a custom allocator using areans
for PLEvents would help performance.
Blocks: 21762
Keywords: perf
Keywords: mozilla1.2
Summary: investigate allocating PLEvents in an arena → [DHTML] Investigate allocating PLEvents in an arena
you want more than an arena, you also need a freelist.  The combination is often
called a "recycler", and is implemented generally for more than one size class
by nsFixedSizeAllocator
(  The
downside is that you may tie up too much memory in the idle or least-use case,
so tune the arena chunk size well.

Summary: [DHTML] Investigate allocating PLEvents in an arena → [DHTML] Investigate allocating PLEvents using a recycler
QA Contact: rakeshmishra → trix
Keywords: mozilla1.2mozilla1.3
Is this something that can be addressed for 1.4 ?
Keywords: mozilla1.3
Blocks: 203448
Maybe this is also related to bug 210602 comment #1

this is a cool idea.. but would this need to be threadsafe? Or are we talking
about events a thread posts to itself? We also have nsRecyclingAllocator which
will avoid free()'ing until a timer goes off.
hmm... up until recently, PLEvents had a much larger footprint (see bug 204962),
so maybe this bug is less significant or perhaps the overhead of a recycling
allocator for PLEvents would be significantly less.
I've attached a patch in bug 213813 that might help with some of these DHTML
issues. I don't expect tremendous gains, but it might be a small step in
improving performance. I'm going to try and get some numbers, but I wanted to
get this out to others that might have more time than I have current. The patch
is at
Assignee: joki → saari
QA Contact: trix → ian
Is this still planned for the future, or is it a lost cause ?
We need evidence that this bug is worth "fixing".  Profiling cycle and memory
use would be helpful.  Comment 0 on its face is not convincing -- avoiding
malloc is a good way to hoard memory in private heaps, reinvent various
thread-safety and memory pressure wheels, etc.

Assignee: saari → nobody
I haven't run into PLEvent allocation as an issue in DHTML per se (haven't seen
it show up in profiles).  I just checked some profiles I have lying about, and
this is pretty typical:

Under PresShell::PostReflowEvent, the breakdown of time spent is the following:

 220 hits in the function itself.
3807 nsEventQueueServiceImpl::GetSpecialEventQueue(int, nsIEventQueue**)
 108 nsCOMPtr_base::~nsCOMPtr_base()
  11 nsEventQueueServiceImpl::GetThreadEventQueue(PRThread*, nsIEventQueue**)
  10 nsCOMPtr_base::begin_assignment()
   8 nsEventQueueImpl::PostEvent(PLEvent*)
   7 nsEventQueueImpl::Release()
   4 ReflowEvent::ReflowEvent(nsIPresShell*)
   1 nsCOMPtr_base::assign_with_AddRef(nsISupports*)

So the actual event creation is at most 5% of the time needed to post the event.
 More likely, it's below 1%...  Similarly, under
nsCSSFrameConstructor::PostRestyleEvent only 2 hits out of 7800 show |operator
new| for the event.  The rest are doing other things.  That's about 0.1% of
total time.

All that said, the issue this was initially filed on is not at all DHTML
related; I don't know why "DHTML" was added to the summary (so removing it).

Back to the original issue in this bug, can someone point me to a flash page
that's actually... like using CPU or something?  The website cited in comment 0
( uses exactly 0 CPU over here (current trunk Linux
build).  So based on that page, this PLEvent thing is quite simply a non-issue.
Summary: [DHTML] Investigate allocating PLEvents using a recycler → Investigate allocating PLEvents using a recycler
Morphing this bug to cover nsIRunnable objects, which now replace PLEvent (see bug 326273).  Unfortunately, now we would only be looking at recycling certain nsIRunnable implementations.
Summary: Investigate allocating PLEvents using a recycler → Investigate allocating gecko events (nsIRunnable impls) using a recycler
If this is an issue (especially with timer events), I'd be interested in using a slab-like allocator for these objects.
(In reply to comment #10)
> Back to the original issue in this bug, can someone point me to a flash page
> that's actually... like using CPU or something?

see bug 341380
That doesn't show any event allocations in the profile, just lots of X/GTK stuff.
QA Contact: ian → events
Closed: 15 years ago
Resolution: --- → INCOMPLETE
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.