Closed Bug 586353 Opened 13 years ago Closed 13 years ago

Shmem creation or initialization is slow

Categories

(Core :: IPC, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
fennec 2.0b2+ ---

People

(Reporter: mbrubeck, Assigned: dougt)

References

Details

MozGetIPCContext takes many times longer than getContext.

In the AnimatedZoom code for Fennec (see bug 584865 for details), on desktop Linux getContext takes less than 1ms while MozGetIPCContext takes between 5 and 50ms.  On a Nexus One running Android 2.2, MozGetIPCContext takes between 600 and 1500ms.
The only difference between GetContext and MozGetIPCContext is that we're backing it with a Shmem; this implies to me that creating Shmems is slow.
Summary: MozGetIPCContext is slow → Shmem creation or initialization is slow
Just to make sure, you're timing a single call, not a loop?  In a loop, the fact that it's not quickstubbed and the security check could kill you (though probably not to 50ms on a desktop...).
(In reply to comment #2)
> Just to make sure, you're timing a single call, not a loop?

Yes, I am timing a single call, using dump(Date.now()) around this line:
http://mxr.mozilla.org/mobile-browser/source/chrome/content/AnimatedZoom.js#65
How large a Shmem are you creating?  Allocating a Shmem should be O(1us) on desktop, and sending the ShmemCreated message should be cheaper than that.  Initializing the Shmem might be slower than for a malloc()-allocated chunk of memory because the malloc() block might be committed already.  But, even then, we're talking maybe O(10us) for extra page faults and so forth.

I can test Shmem-only creation time in the IPDL test harness if I know the typical canvas size.
(In reply to comment #4)
> I can test Shmem-only creation time in the IPDL test harness if I know the
> typical canvas size.

We are creating a canvas of up to 1600x960px.
Thanks.  Hm, that's larger than I thought, but still shouldn't be worse than O(1ms) for POSIX shmem.

BUT ... let me back up a sec ... Joe, this is the "Native ID" SysV canvas that we create and then share to X11, right?  That blows my POSIX numbers out of the water.  50ms still sounds really high, but if we're causing a lot of X11 traffic (especially synchronous traffic), it's more believable.
It happens on Android too, though :(
Before I forget: quick summary of what I saw on my desktop today.  Adjust up times quoted by a factor of ~10 (or more) for on-device.

 - creating (and not initializing) a "basic" IPDL shmem segment took around 8ms (!!!) because borrowed code is using mkstemp() followed by unlink() on /dev/shm to create an anonymous shmem segment.  This time is ridiculously high, and Android is going to suffer, so we should replace this code with the POSIX interface (bug 523172).
 - creating (and not initializing) a SysV IPDL shmem segment was around 75us, which seems higher than necessary but OK (might be committing and initializing to 0 under the covers, which would make more sense).
 - for MozGetIPCContext on Gtk/Ubuntu 10.4/recent NVIDIA card/NVIDIA drivers, initializing its two X11 surfaces and XSync()ing took a highly variable time, between ~70us-1000us.  That plus clearing them took up to ~3ms as measured by Date.now(), but as its resolution is 1ms that number isn't very useful.
Depends on: 523172
tracking-fennec: --- → ?
tracking-fennec: ? → 2.0b2+
Assignee: nobody → doug.turner
On android we're using ashmem rather than POSIX shmem, and on maemo we're using X surfaces, so I'm going to close this bug.  Shared surface init is now in the hands of the content process too, off the startup critical path.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.