ChromeUtils.addProfilerMarker - new API to add profiler markers from JS code
I recently landed a new scriptable API
<https://bugzilla.mozilla.org/show_bug.cgi?id=1608556> to add profiler
markers: ChromeUtils.addProfilerMarker.
This makes it possible for chrome privileged JS code to insert profiler
markers that (optionally) have a duration and an associated text.
Examples:
- Adding a marker without duration:
ChromeUtils.addProfilerMarker("markerName");
- Adding a marker showing the time it took to do something:
let startTime = performance.now();
/* do stuff */
ChromeUtils.addProfilerMarker("markerName", startTime);
The performance object is available in windows and workers. In JS
modules, use Cu.now() instead of performance.now().
- Adding a marker with a duration and an associated extra string:
ChromeUtils.addProfilerMarker("markerName", startTime, "marker text");
Hopefully, this should make it easier to show clearly in the profiler what
our JS code is doing. The first use I made of this was to show the OS.File
operations that are done asynchronously (example profile:
https://perfht.ml/2RhAKXF).
Scriptable marker APIs that already existed:
- Adding a marker from XPCOM-enabled contexts:
if (Services.profiler) {
Services.profiler.addMarker("markerName");
}
The null check was required to avoid exceptions on tier3 platforms that
don't implement the profiler service.
We will probably want to deprecate this API and migrate all existing
callers.
- Adding a 'UserTiming' marker with a duration in a window or worker:
performance.mark("markName");
/* do stuff */
performance.measure("marker text", "markName");
This will add a marker named UserTiming with the "marker text"
associated text, and the duration between the performance.mark and the
performance.measure calls. However, the performance.measure
implementation is slow
<https://bugzilla.mozilla.org/show_bug.cgi?id=1373086> enough that it
adds significant overhead if called frequently.
This API will remain available, but should be avoided for chrome
privileged code.
--
Florian Quèze
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to remove: the 'Memory usage of Subprocesses' table from about:performance
On Thu, Jul 12, 2018 at 1:18 AM, Eric Rahm wrote: > What performance issues are you seeing? RSS and USS should be relatively > lightweight and the polling frequency isn't very high. It seems ResidentUniqueDistinguishedAmount does blocking system calls, resulting in blocking the main thread for several seconds in the worst case. Here's a screenshot of a profile showing it: https://i.imgur.com/DjRMQtY.png (unfortunately that profile is too big and fails to upload with the 'share' feature). There's also a memory leak in the implementation, after leaving about:performance open for a couple hours, there was more than 300MB of JS "Function" and "Call" objects (about:memory screenshot: https://i.imgur.com/21YNDru.png ) and the devtools' Memory tool shows that this is coming from the code queuing updates to that subprocess memory table: https://i.imgur.com/04M71hg.png Florian -- Florian Quèze ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to remove: the 'Memory usage of Subprocesses' table from about:performance
Context: we are currently redesigning about:performance to make it more useful for users. This section of the current about:performance page provides information that isn't actionable for users, and collecting this information causes performance issues, so I think it's time to remove it. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1474990 for the removal. If someone uses this information and strongly thinks we should keep it (eg. by moving it to about:memory), now is the time to speak up. Thanks, Florian -- Florian Quèze ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: eslint will now error for uses of Components.{classes, interfaces, utils, results}, please use Cc, Ci, Cu, Cr instead
As of bug 1433175, the mozilla/use-cc-etc eslint rule is enabled by default. This means that any use of Components.classes, Components.interfaces, Components.utils or Components.results will cause linting errors. Please use the Cc, Ci, Cu, Cr shorthands instead (they are defined in all chrome scopes since bug 767640). To enable this rules, I had to convert all the remaining occurrences in the tree, which means I just landed a big patch that's likely to bitrot other patches. Sorry for the inconvenience. -- Florian Quèze ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Recording code loaded during startup, and avoiding regressions
handling user events: resource://gre/modules/FxAccountsCommon.js modules loaded before handling user events: resource://gre/modules/ContentPrefStore.jsm modules loaded before handling user events: resource://gre/modules/PageThumbs.jsm modules loaded before handling user events: resource://gre/modules/PushRecord.jsm modules loaded before handling user events: resource://pdf.js/PdfjsChromeUtils.jsm modules loaded before handling user events: resource://services-crypto/utils.js modules loaded before handling user events: resource://gre/modules/CrashSubmit.jsm modules loaded before handling user events: resource://gre/modules/NewTabUtils.jsm modules loaded before handling user events: resource://gre/modules/PushService.jsm modules loaded before handling user events: resource://gre/modules/PushServiceWebSocket.jsm modules loaded before handling user events: resource://devtools/shared/loader-plugin-raw.jsm modules loaded before handling user events: resource://gre/modules/CertUtils.jsm modules loaded before handling user events: resource:///modules/ExtensionsUI.jsm modules loaded before handling user events: resource://pdf.js/PdfStreamConverter.jsm modules loaded before handling user events: resource://gre/modules/ContentPrefUtils.jsm modules loaded before handling user events: resource:///modules/Social.jsm modules loaded before handling user events: resource:///modules/sessionstore/TabState.jsm modules loaded before handling user events: resource://gre/modules/ContentPrefService2.jsm modules loaded before handling user events: resource://gre/modules/commonjs/toolkit/loader.js modules loaded before handling user events: resource://gre/modules/addons/ProductAddonChecker.jsm modules loaded before handling user events: resource://gre/modules/FxAccountsWebChannel.jsm modules loaded before handling user events: resource:///modules/WindowsPreviewPerTab.jsm modules loaded before handling user events: resource://gre/modules/AppMenuNotifications.jsm modules loaded before handling user events: resource://gre/modules/osfile/ospath_unix.jsm modules loaded before handling user events: resource://gre/modules/FxAccounts.jsm modules loaded before handling user events: resource://pdf.js/PdfJs.jsm modules loaded before handling user events: resource:///modules/ProcessHangMonitor.jsm modules loaded before handling user events: resource://gre/modules/WebChannel.jsm modules loaded before handling user events: resource://gre/modules/PushCrypto.jsm modules loaded before handling user events: resource://devtools/shared/Loader.jsm modules loaded before handling user events: resource://gre/modules/FxAccountsStorage.jsm modules loaded before handling user events: resource://services-common/rest.js modules loaded before handling user events: resource://gre/modules/PushServiceHttp2.jsm modules loaded before handling user events: resource://gre/modules/DateTimePickerHelper.jsm modules loaded before handling user events: resource:///modules/SocialService.jsm modules loaded before handling user events: resource://gre/modules/AutoCompletePopup.jsm services loaded before handling user events: @ mozilla.org/browser/search-service;1 services loaded before handling user events: @ mozilla.org/network/cache-service;1 services loaded before handling user events: @mozilla.org/windows-taskbar;1 services loaded before handling user events: @ mozilla.org/embedcomp/default-tooltiptextprovider;1 services loaded before handling user events: @ mozilla.org/content-pref/service;1 services loaded before handling user events: @ mozilla.org/spellchecker/engine;1 services loaded before handling user events: @ mozilla.org/autocomplete/search;1?name=unifiedcomplete services loaded before handling user events: @ mozilla.org/network/dashboard;1 services loaded before handling user events: @ mozilla.org/uriloader/handler-service;1 services loaded before handling user events: @ mozilla.org/spellchecker/personaldictionary;1 services loaded before handling user events: @ mozilla.org/dom/slow-script-debug;1 services loaded before handling user events: @ mozilla.org/network/protocol;1?name=wss services loaded before handling user events: @mozilla.org/widget/clipboard;1 -- Florian Quèze ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switching to async/await from Task.jsm/yield
On Mon, Mar 27, 2017 at 9:42 PM, Dave Townsend <dtowns...@mozilla.com> wrote: > lets go ahead with this and avoid using Task.jsm in the future. Patches to remove Task.jsm usage from browser/ and toolkit/ are now available in https://bugzilla.mozilla.org/show_bug.cgi?id=1353542 along with the scripts that generated them. I currently expect to land them on Friday morning. Given the size of the patches (2040 files changed, more than 35k lines changed), this landing will likely happen with a tree closure, to avoid merging conflicts between inbound and autoland. If you have WIP front-end patches that are almost ready to land, I would suggest landing them soon to avoid bitrot. Florian -- Florian Quèze ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How would you like to spell check this?
On Sun, Aug 30, 2015 at 10:17 PM, Jörg Knobloch <jo...@jorgk.com> wrote: > So please voice your objections to the proposed solution, if any ;-) As someone mentioned already, lots of websites are actually communication tools (eg. webmail, chat, social networks), and there's no way the website can know in advance in which language I'll want to type (I write half the time in French and half the time in English). My personal experience is that touching a context menu to switch the dictionary all the time is too much effort, so I gave up and am now used to completely ignoring the red underlines. The solution I would like to see implemented (and I'm willing to help) is automatic detection of the language. We already ship language detection code (http://mxr.mozilla.org/mozilla-central/source/browser/components/translation/LanguageDetector.jsm) and this could be reused for spell checking. Of course we can't guess the language when the user starts typing (so we'll still need the mechanisms you discussed), but as soon as we have a couple words, the detection is pretty reliable. This would of course need a way to pref it off for people who speak a single language and would be annoyed if every once in a while the dictionary is switched automatically; but I think it would make the spell checker significantly more usable for multi-language users. Florian -- Florian Quèze ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: WebRTC Audio device (microphone) selector
On Tue, Nov 4, 2014 at 10:47 AM, Balázs Sándor balazs.san...@virtual-call-center.eu wrote: Hi all! Hi, I added an observer for getUserMedia:request but it never called. I'm guessing your xulrunner application calls getUserMedia from chrome:// code. If so, your observer is never called because the code at http://mxr.mozilla.org/mozilla-central/source/dom/media/MediaManager.cpp#1730 skips the request notification and just grants access immediately to the default devices for gUM calls from privileged code. Assuming your want to make your application work with currently released versions of xulrunner, I would look for ways to load unprivileged code in your application (not completely sure how to do that). If you can build xulrunner yourself from newer code, you could maybe submit a patch to change the current media.navigator.permission.fake preference to something that would also apply to privileged code. Florian -- Florian Quèze ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Too many system compartments at start-up
Le jeudi 24 avril 2014 10:51:12 UTC+2, Nicholas Nethercote a écrit : I've given the list of current start-up (+30s) modules below. This list contains several compartments for XPCOM components handling the command line (eg. nsSetDefaultBrowser.js or nsDefaultCLH.js). I wouldn't expect them to still be alive 30s after startup. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=975639 on this a while ago. Florian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
