Saturday, November 19, 2011

f1upgradeutility.exe using 100% CPU

In the hope of making the Google results for f1upgradeutility.exe a little more helpful, I'd like to note that this application using 100% (or 50% or 25% depending on the number of cores you have) of CPU is usually found in c:\Program Files\NSS\f1upgradeutility.exe and belongs to the Nemesis Service Suite, which you've probably installed to flash your Nokia device.

Saturday, September 24, 2011

Sublime Text 2: diff syntax highlighting with a light background color scheme

I recently discovered a new text editor, Sublime Text 2, which I quite like. By default it uses a dark-background color scheme, and while it comes with a few light schemes, none of them have proper syntax highlighting for "diff" files. Fortunately it turned out to be easy to fix:
  1. cd into the Packages/Color Scheme - Default directory.
  2. Copy the scheme you like, e.g. cp iPlastic.tmTheme iPlastic-my.tmTheme.
  3. Change the new file as follows.
  4. To change the theme, edit your preferences file to say
    "color_scheme": "Packages/Color Scheme - Default/iPlastic-my.tmTheme",
    To see the effect of your changes, just save the preferences file.

--- iPlastic.tmTheme	2011-07-31 02:14:25.000000000 +0400
+++ iPlastic-my.tmTheme	2011-09-25 01:29:18.000000000 +0400
@@ -6,5 +6,5 @@
 	<string>Jeroen van der Ham</string>
 	<key>name</key>
-	<string>iPlastic</string>
+	<string>iPlastic-my</string>
	<key>settings</key>
 	<array>
@@ -280,4 +280,50 @@
 			</dict>
 		</dict>
+		<dict>
+			<key>name</key>
+			<string>diff.header</string>
+			<key>scope</key>
+			<string>meta.diff.header</string>
+			<key>settings</key>
+			<dict>
+				<key>foreground</key>
+				<string>#ffffff</string>
+				<key>background</key>
+				<string>#77aadd</string>
+			</dict>
+		</dict>
+		<dict>
+			<key>name</key>
+			<string>diff.deleted</string>
+			<key>scope</key>
+			<string>markup.deleted</string>
+			<key>settings</key>
+			<dict>
+				<key>foreground</key>
+				<string>#F92672</string>
+			</dict>
+		</dict>
+		<dict>
+			<key>name</key>
+			<string>diff.inserted</string>
+			<key>scope</key>
+			<string>markup.inserted</string>
+			<key>settings</key>
+			<dict>
+				<key>foreground</key>
+				<string>#11aa11</string>
+			</dict>
+		</dict>
+		<dict>
+			<key>name</key>
+			<string>diff.changed</string>
+			<key>scope</key>
+			<string>markup.changed</string>
+			<key>settings</key>
+			<dict>
+				<key>foreground</key>
+				<string>#ff2222</string>
+			</dict>
+		</dict>
	</array>
 	<key>uuid</key>

Wednesday, March 23, 2011

Debugging crashes

Two interesting posts on debugging crashes I came across this month:

Sunday, March 13, 2011

Startup performance of Addon SDK-based extensions

The addons.mozilla.org roadmap for 2011 has improving the add-ons performance as one of this year's goals, so after finishing with my XUL extensions project for the weekend, I did some quick measurements to see what effect add-ons built with the SDK have on the Firefox startup time.

I posted this message to the Add-on SDK discussion group, but reproducing it here anyway.

According to my tests (Mac OS X (10.5) with the latest Minefield and the latest Add-on SDK using getStartupInfo()):
  • an empty SDK-based extension (empty main.js) adds ~20 ms to the 700 ms baseline warm startup time (3%), which is tolerable, but
  • the default extension created with 'cfx init' (adds a simple widget and loads the tabs module) adds more than 200 ms (28%) to the warm startup!
I ran some poor man profiling to check a hypothesis that most of this cost is in the module system (require()). It is very rough, but it showed how most (75%) of the time was spent:
  • 25% (50ms) running es5.js in each of the 38 distinct modules loaded
  • 15% (30ms) is other initialization operations with the sandbox (creating sandboxes, setting properties)
  • 10% (20ms) is spent in fs.getFile(), presumably loading the modules from disk
  • 25% (50ms) spent evaluating the module code itself, not counting the require() costs listed above.
Here are the details of my instrumentation and the results: legend, data:

Counter Hit count Time spent, msAttributed to the
securable-module infrastructure /
to the user-level code?
start loading 3837user
fs.getFile()3819s-m
up to createSandbox380s-m
createSandbox3817s-m
setupSandbox, part 1381s-m
setupSandbox, part 2 - modifyModuleSandbox3854s-m
setupSandbox, part 33815s-m
before evaluate380s-m
after evaluate3852user
finished380s-m

The list of all 38 modules loaded by a simple extension using widget and tabs (indenting shows require() dependencies):

  • plain-text-console
  • memory
    • unload
  • main
    • widget
      • xul-app
      • api-utils
      • panel
        • content
          • content/loader
            • events
              • traits
                • traits/core
            • url
            • file
              • byte-streams
              • text-streams
              • xpcom
          • content/symbiont
            • ./worker
              • cuddlefish
                • securable-module
              • timer
            • hidden-frame
              • errors
            • observer-service
      • window-utils
    • tabs
      • windows
        • list
        • windows/tabs
          • tabs/tab
            • utils/function
            • tabs/events
            • utils/thumbnail
            • utils/data
        • windows/dom
        • windows/loader

Saturday, January 08, 2011

JavaScript HTTP server as a module for Jetpack SDK

I converted the JS HTTP server (httpd.js) to a Jetpack / Addon SDK module for use in unit tests.

Source on GitHub.

Here's an example test using it:

exports.testBasicHTTPServer = function(test) {
  var port = 8080;
  var basePath = require("file").dirname( // the directory...
                   require("url").toFilename(__url__)); // ...this file is in
  var {startServerAsync} = require("httpd")
  var srv = startServerAsync(port, basePath);

  test.waitUntilDone();  

  // Request this very file.
  var Request = require('request').Request;
  Request({
    url: "http://localhost:" + port + "/test-httpd.js",
    onComplete: function (response) {
      test.assertEqual(response.text.indexOf(
        "exports.testBasicHTTPServer = function(test) {"), 0);
      done();
    }
  }).get();

  function done() {
    srv.stop(function() {
      test.pass();
      test.done();
    });
  }
};