Summary: Added stats, so that we know how much people have to wait when opening plugin after we open the queue GK
Reviewed By: jknoxville
Differential Revision: D19598730
fbshipit-source-id: f955123f2bae5b870eada8f787385d6c0450453e
Summary: For the navigation plugin we want to opt-out from the "enabled" and "process messages later" optimizations, because it's events should be immediately processed to reflect the changes in the topbar for navigation purposes
Reviewed By: jknoxville
Differential Revision: D19554297
fbshipit-source-id: 4bd49b5d1327feea6dea52e86d9dbc9d54a5dbee
Summary: The navigation plugin threw exceptions, as the defaultPersisted state was not mixed into the already stored state, making some fields unreadable
Reviewed By: jknoxville
Differential Revision: D19554291
fbshipit-source-id: 57f045aa1eae10682e44d479b9aecb51f0391b9e
Summary: Discovered that all gathered plugin stats where empty due to mis-using Object.entries. Fixed that. Also added a accumulated cpuTime metric, which should be great for a uniform trend line.
Reviewed By: jknoxville
Differential Revision: D19517279
fbshipit-source-id: a6df83eea000a5d59fe692a3795fd58ae6457821
Summary:
This diff improves two things:
1. Stats are now gathered on every `trackUsage` tick, rather than only when there is a selection
2. The stats now include a delta to compare it with the previous tick
Reviewed By: passy
Differential Revision: D19514231
fbshipit-source-id: 1854c1dc03c63a03db8c7040c185d2629e1b9ea2
Summary:
Since background plugins don't receive data anymore when not starred, we should hint the user about this.
For this diff, I reused the existing statusbar. Although this solution is quite ugly, I think it is better than introducing yet another notification / warning mechanism. Probably we should revisit the layout of this status bar in the future.
Reviewed By: jknoxville
Differential Revision: D19251588
fbshipit-source-id: 1dfd07be383d4ba318f344ebff4b08ed36194c58
Summary:
From several reviews / early feedbacks it was suggested several times to use the star mechanism to distinguish which plugins are allowed to send messages. This diff implements that:
- If a plugin is not selected, and not starred, it will drop the messages it received in the background
- This logic is still behind the same GK
- I think this change warrants upping the message queue limits significantly
- A future optimization would be to disable sending messages from the device side of things to reduce bridge usage, but that change is probably a lot more complicated with less impact
- In the next diff I'll make clear from UI perspective that unstarred plugins don't queue messages
In the attach video one can see how graphQL plugin keeps storing messages if it is starred, but if it isn't starred and not selected either, it will skip messages
{F225692819}
Reviewed By: jknoxville
Differential Revision: D19250928
fbshipit-source-id: 7e6af0eb6830dc79951cfd206e05b44061f1b14a
Summary: `flipperPrintPluginBackgroundStats()` tended to report the class name rather than the given plugin id
Reviewed By: jknoxville
Differential Revision: D19250706
fbshipit-source-id: 6035892bacf6a592d8c510320d5e003fac580ec7
Summary: This diff makes sure that pending queues for plugins that are selected are processed before making a flipper export.
Reviewed By: jknoxville
Differential Revision: D19194211
fbshipit-source-id: e076375889450407e7f94384051719f3bbc415ee
Summary:
To avoid plugins to collect data forever and store it (if they are never opened), introduced a hard-coded default limit on how many events will be preserved.
A semantic change is that plugins have to be potentially resistant against missing events. So far, during testing, this didn't seem to cause any problems.
Reviewed By: jonathoma
Differential Revision: D19175912
fbshipit-source-id: 828be941e76b7356c9f5be7e5a49de9a7a31b0d2
Summary: This introduces the necessary UI changes, to kick off and render event progressing process where needed
Reviewed By: jknoxville
Differential Revision: D19175450
fbshipit-source-id: 61e3e8f59eeebf97eedbe715fa7db320286543e2
Summary:
This diff introduces the logic for queueing incoming messages rather then directly processing them you are behind the `flipper_event_queue` GK.
The reason the queue processing is a bit complicated is to make the queue can be processed non-blocking, can be cancelled, and is safe to concurrency issues.
The idea here is that the queue is processed when we switch to a plugin, report it's progress, and abort the process when switching to another plugin without loosing any work.
This diff does not include
[x] updates to the UI (**SO DON"T LAND IN ISOLATION**)
[x] metrics to see the effect
The effect of the changes can be seen when profiling the application, before this change there are very regular CPU spikes (see the small yellow bar on the top):
https://pxl.cl/TQtl
These go away when the events are no longer processed
https://pxl.cl/TQtp
Reviewed By: nikoant
Differential Revision: D19095564
fbshipit-source-id: 0b8c3421acc4a4f240bf2aab5c1743132f69aa6e
