Closed Bug 922023 Opened 6 years ago Closed 6 years ago

[meta] Tracking Perf Bug for Notes+ App


(Firefox OS Graveyard :: Gaia, defect)

Gonk (Firefox OS)
Not set


(Not tracked)



(Reporter: mrbkap, Assigned: mchang)



(Keywords: perf, Whiteboard: [c= p=3 s= u=])

+++ This bug was initially created as a clone of Bug #884394 +++

Mason, I'm setting you as the assignee because you mentioned you were going to look at this, please update the assignee if that's not actually the case.

In bug 884394, we got to a point where we can import the gigantic notes in the infamous test account that's been kicking around. We now need to make the user experience when dealing with the given notes better. Here are some STR to profile with:

1. Import the notes through the UI.

==> How long does it take before the sync finishes
1. Open the app
2. Open the "Notebooks" sidebar
3. Select "matias-doit9"

==> How long does it take before the list is displayed.
1. Open the app
2. Open the "Notebooks" sidebar
3. Select "matias-doit9"
4. Select "lorem"

==> How long does it take before we load the note and the UI
==> Scrolling is *super* laggy

We might want to open additional bugs to track the various STRs.
Summary: Notes+ app crashes upon resource transfer → Profile Notes+ when dealing with extremely large notes
Oh, and just to spam everybody once more, the app's source is hosted at

Also, the note "Image" should probably be profiled as well.
It would be much easier if we could install the app via the marketplace.

evme submitted it a while ago according to
Wil can you help here with the approval process?
Flags: needinfo?(clouserw)
(In reply to Gregor Wagner [:gwagner] from comment #2)
> It would be much easier if we could install the app via the marketplace.
> evme submitted it a while ago according to
> Wil can you help here with the approval process?

You can install Notes here -
There is possibly an updated version that is awaiting review. Matias — can you provide updated info here.
Whiteboard: [c= p= s= u=]
Here is a profile of the Notes+ App:

It looks like a lot of time is spent reflowing if I'm reading it correctly. A few notes about this profile:

1) This is with the matias-doit9 test account, NOT the matias_evme account.
2) This is on BRANCH=v1.2 on a Hamachi device. The scrolling lag that Blake is reporting is not showing up on the Hamachi device. Scrolling isn't super smooth, but isn't supper laggy as well.

Timings as requested by Blake (All done with imprecise me pushing timer on my iphone to start/stop) :

1) Evernote Login -> Notebook Display - ~20 seconds
2) Reselect 'matias-doit9' notebook -> Lorum Ipsum display ~12 seconds
3) Click lorum ipsum -> Text showing ~14 seconds
4) Scroll response -> Instant after text loads.
Flags: needinfo?(clouserw)
Whiteboard: [c= p= s= u=] → [c= p= s=3 u=1.2]
blocking-b2g: koi? → koi+
Priority: -- → P1
During the loading phase, according to the profile, we spend 33.2% of our time reflowing ( 

There isn't a lot of time spent in Javascript, but in the time that is spent, 66% of the time is spent in BrowserElementPanning.js:397 doScroll().
Whiteboard: [c= p= s=3 u=1.2] → [c= p=3 s=3 u=1.2]
Summary: Profile Notes+ when dealing with extremely large notes → [meta] Tracking Perf Bug for Notes+ App
blocking-b2g: koi+ → ---
Target Milestone: --- → 1.2 C3(Oct25)
New numbers based on the new Notes+ app:

Using the matias-doit9 account with 2 notes. 1 note contains a picture, the other contains 50 paragraphs, 4544 words, 30900 bytes of Lorum Ipsum.

Timings on an otoro device on 1.2:

Evernote login -> all notes -> notes displayed: ~8 seconds
Touch text note -> note showing up: ~3 seconds
Scroll response -> laggy. I can't instantly start scrolling, but starts fast enough that I can't measure accurately with a separate physical timer.

Other timings: 
Opening the notebook sidebar: < 1 second.
Selecting a notebook: < 1 second

If we need more precise timings, we can instrument the app rather than using a separate physical timer.
Per discussion with :gwagner, we want to rerun numbers on memory usage on b2g-desktop and compare against previous numbers mentioned in bug 884394:

Bytes Used	Count		Symbol Name
 251.03 MB      99.9%	990	 	                      nsThread::ProcessNextEvent(bool, bool*)
  94.24 MB      37.5%	404	 	                       mozilla::dom::indexedDB::AsyncConnectionHelper::Run()
  94.24 MB      37.5%	398	 	                        mozilla::dom::indexedDB::AsyncConnectionHelper::OnSuccess()
    848 Bytes    0.0%	6	 	                        mozilla::dom::indexedDB::IDBRequest::NotifyHelperCompleted(mozilla::dom::indexedDB::HelperBase*)
  91.98 MB      36.6%	59	 	                       nsInputStreamReadyEvent::Run()
  64.81 MB      25.8%	526	 	                       nsTimerEvent::Run()
     32 Bytes    0.0%	1	 	                       mozilla::dom::indexedDB::FinishTransactionRunnable::Run()
     48 Bytes    0.0%	2	 	                 __CFRunLoopDoObservers

Once bug 923961 lands, I will rerun, and if numbers look good on memory usage, we can close this bug.
Depends on: 923961
Severity: critical → normal
Priority: P1 → --
Whiteboard: [c= p=3 s=3 u=1.2] → [c= p=3 s=3 u=]
Target Milestone: 1.2 C3(Oct25) → ---
Whiteboard: [c= p=3 s=3 u=] → [c= p=3 s= u=]
Initially, I tried to login to the evernote account, but at the moment, I can't collect numbers from a fresh notes+ install with the b2g-desktop Out of Process patches: 

Bug 891882 Solo - Gives me a white screen with gaia, will not work
Bug 914584 && Bug 923961 - Cannot log into evernote, everytime I try to login, it just refreshes to the login page again.
Bug 923961 Solo - Works, but can't click matias-doit9 notebook. I'm getting this error: ###!!! ASSERTION: Some mouse button down events are nested?: '!aDocument || !mMouseDownEventHandlingDocument', file /Volumes/firefoxos/mozilla-aurora/content/events/src/../../../dom/base/nsFocusManager.h, line 83 when click on notbeook

I did get some numbers using the following configuration:

Login to matias-doit9 notebook with a clean mozilla-aurora build.
Apply patch 923961 & patch 914584
Rebuild b2g-desktop
Change from my notebook -> All notes -> Lorum Ipsum
Collect instruments allocations:

b2g process:
Bytes Used	Count		Symbol Name
  42.20 MB      58.7%	82113	 	start
  29.24 MB      40.6%	42052	 	thread_start
 309.05 KB       0.4%	433	 	start_wqthread

Notes+ Process:
Bytes Used	Count		Symbol Name
  93.55 MB      90.7%	171123	 	                     nsThread::ProcessNextEvent(bool, bool*)
  84.02 MB      81.5%	149560	 	                      nsTimerEvent::Run()
  84.02 MB      81.5%	149560	 	                       nsTimerImpl::Fire()
  83.03 MB      80.5%	149489	 	                        mozilla::RefreshDriverTimer::Tick()
  83.01 MB      80.5%	148366	 	                         nsRefreshDriver::Tick(long long, mozilla::TimeStamp)
  73.17 MB      70.9%	81139	 	                          nsViewManager::ProcessPendingUpdatesForView(nsView*, bool)
  73.15 MB      70.9%	80908	 	                           PresShell::Paint(nsView*, nsRegion const&, unsigned int)

Bytes Used	Count		Symbol Name
  94.97 MB      92.1%	190397	 	start

I'm not quite sure I'm reading these numbers right or that I'm doing it correctly because of the patch issues, but it looks like there is less than 250 MB.
Flags: needinfo?(anygregor)
Depends on: 891882, 914584
> I'm not quite sure I'm reading these numbers right or that I'm doing it
> correctly because of the patch issues, but it looks like there is less than
> 250 MB.

Yeah those numbers show short time allocations over time and thats not super useful. I looked at the numbers again with Mason and we don't see any big spikes any more with the notes app but the ideal OOP configuration that I used doesn't currently work.
Flags: needinfo?(anygregor)
Updated instruments numbers for the b2g process:

Bytes Used	Count		Symbol Name
   1.17 MB      68.2%	3978	 	malloc
 254.73 KB      14.5%	1876	 	 moz_xmalloc
 190.25 KB      10.8%	127	 	 js::detail::BumpChunk::new_(unsigned long)
 176.00 KB      10.0%	4	 	 js::ScriptSource::chars(JSContext*)
 105.27 KB       6.0%	53	 	 PORT_Alloc_Util
  67.00 KB       3.8%	4	 	 gfxImageSurface::AllocateAndInit(long, int, bool)
  64.00 KB       3.6%	1	 	 mozilla::gfx::SourceSurfaceCG::InitFromData(unsigned char*, mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&, int, mozilla::gfx::SurfaceFormat)
  54.00 KB       3.0%	30	 	 PL_ArenaAllocate

For the notes+ App:
Bytes Used	Count		Symbol Name
   2.18 MB      77.5%	7404	 	malloc
 382.59 KB      13.3%	4633	 	 moz_xmalloc
 318.00 KB      11.0%	658	 	 js::detail::BumpChunk::new_(unsigned long)
 200.00 KB       6.9%	25	 	 PL_ArenaAllocate
 192.50 KB       6.6%	4	 	 mozilla::VectorBase<char16_t, 32ul, js::ContextAllocPolicy, js::Vector<char16_t, 32ul, js::ContextAllocPolicy> >::convertToHeapStorage(unsigned long)
 134.88 KB       4.6%	186	 	 nsStringBuffer::Alloc(unsigned long)
 134.54 KB       4.6%	183	 	 JSStructuredCloneReader::readString(unsigned int)

I've also updated the wiki OOM section on how to collect memory usage using desktop-b2g ( I'll close the bug now per discussion with Gregor. If notes+ performance becomes an issue again, we can reopen.
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.