Closed Bug 922023 Opened 6 years ago Closed 6 years ago
[meta] Tracking Perf Bug for Notes+ App
+++ 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 https://github.com/EverythingMe/ffos-notes/tree/phase2 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 https://bugzilla.mozilla.org/show_bug.cgi?id=884394#c65 Wil can you help here with the approval process?
(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 > https://bugzilla.mozilla.org/show_bug.cgi?id=884394#c65 > Wil can you help here with the approval process? You can install Notes here - https://marketplace.firefox.com/app/notesplus.
There is possibly an updated version that is awaiting review. Matias — can you provide updated info here.
Here is a profile of the Notes+ App: https://people.mozilla.org/~bgirard/cleopatra/#report=1fea82cd50f2351b39950a5b26419525acb3671b 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.
Whiteboard: [c= p= s= u=] → [c= p= s=3 u=1.2]
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
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) → ---
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) Total: 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.
> > 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.
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 (https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Debugging/Debugging_OOMs). I'll close the bug now per discussion with Gregor. If notes+ performance becomes an issue again, we can reopen.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.