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.

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>

Debugging crashes

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

• Slides (with detailed notes) from the “Forensic Debugging” talk by Valve's Elan Ruskin.
• How to rescue a broken stack trace: Recovering the EBP chain by Raymond Chen.

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, ms	Attributed to the securable-module infrastructure / to the user-level code?
start loading	38	37	user
fs.getFile()	38	19	s-m
up to createSandbox	38	0	s-m
createSandbox	38	17	s-m
setupSandbox, part 1	38	1	s-m
setupSandbox, part 2 - modifyModuleSandbox	38	54	s-m
setupSandbox, part 3	38	15	s-m
before evaluate	38	0	s-m
after evaluate	38	52	user
finished	38	0	s-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

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();
    });
  }
};