Deseret Tech

September 30, 2009

Mozilla needs to step it up

Filed under: software,whining — jeffc @ 3:56 am

I’m currently using the Chromium developer builds for Linux and it’s amazing how Chromium is still so much faster than Firefox even though Google Chrome has been out for over a year now and Mozilla just performed a major release this summer.

It’s pretty obvious that TraceMonkey in its present state doesn’t hold up to either V8 or SquirrelFish Extreme (which score rather similarly in my experience, usually with SFX a relatively slight margin ahead of V8). I understand that TraceMonkey is much more competitive on Windows, but I almost never use Windows so I don’t care to look into that.

Mozilla really needs to focus on getting consistently good performance if they want to remain relevant.

Chromium is a godsend because of the competition and development it has both encouraged and provided in regard to in-browser JavaScript VMs. It is crucial to the future of the web that we get this show on the road, because fast JavaScript and HTML 5 canvas means the end of proprietary, patent-encumbered necessary evils like Flash and Silverlight. It’s almost impossible to browse without Flash anymore, and that must change.

I’m annoyed at Mozilla because despite their overtures and aggrandizing, Firefox is improving very slowly, and still can’t seem to cope with many of the same demos that Chrome 1.0 was chewing through without issue.

The sad thing is that I don’t really want to switch to Chromium and I don’t want the world to switch to it either. Google has way too much control as it is, with access to almost everyone’s email, search history, etc., and the ability to effectively kill off anyone who depends on referrals from search traffic (most sites see 80%-90% of external search referrals from Google) and Firefox already has thousands of good extensions and themes, not to mention a slight rapport and installed base in the general public.

But Chromium is just so much faster and safer; even if I could bring myself to ignore the 250% speed difference in _just_ the JavaScript VM (no mention here of Chromium’s vastly faster user interface), Firefox has been crashing a lot lately due to erroroneous packaging by my distro, but if and when Chromium crashes, it only brings down the affected tab (every tab is its own process in Chromium) and everything else remains intact, which, at least this week, has made browsing much more pleasant.

Chromium’s every-tab-as-a-process technique also makes exploits much more difficult.

These are the results I just got from Sunspider, against the latest available Chromium and Firefox 3.7 nightly builds on an up-to-date Arch Linux install with kernel 2.6.31.

This is a 32-bit Chromium against a 64-bit Firefox, but the 32-bit to 32-bit results were similar and actually a bit less favorable to Firefox.

TEST                   COMPARISON            FROM                 TO             DETAILS

=============================================================================

** TOTAL **:           2.22x as fast     1092.2ms +/- 4.7%   492.6ms +/- 3.6%     significant

=============================================================================

  3d:                  2.10x as fast      154.4ms +/- 1.5%    73.4ms +/- 4.3%     significant
    cube:              1.87x as fast       47.2ms +/- 6.0%    25.2ms +/- 5.4%     significant
    morph:             1.40x as fast       35.0ms +/- 0.0%    25.0ms +/- 7.0%     significant
    raytrace:          3.11x as fast       72.2ms +/- 2.8%    23.2ms +/- 5.9%     significant

  access:              3.50x as fast      130.8ms +/- 1.6%    37.4ms +/- 6.5%     significant
    binary-trees:      20.0x as fast       40.0ms +/- 3.1%     2.0ms +/- 44.0%     significant
    fannkuch:          4.00x as fast       55.2ms +/- 1.9%    13.8ms +/- 9.9%     significant
    nbody:             1.28x as fast       23.6ms +/- 2.9%    18.4ms +/- 3.7%     significant
    nsieve:            3.75x as fast       12.0ms +/- 12.7%     3.2ms +/- 17.4%     significant

  bitops:              ??                  36.6ms +/- 6.2%    37.0ms +/- 4.1%     not conclusive: might be *1.01x as slow*
    3bit-bits-in-byte: ??                   1.6ms +/- 42.6%     2.4ms +/- 28.4%     not conclusive: might be *1.50x as slow*
    bits-in-byte:      1.18x as fast       10.6ms +/- 6.4%     9.0ms +/- 9.8%     significant
    bitwise-and:       *4.27x as slow*      2.2ms +/- 25.3%     9.4ms +/- 7.2%     significant
    nsieve-bits:       1.37x as fast       22.2ms +/- 8.3%    16.2ms +/- 6.4%     significant

  controlflow:         10.7x as fast       34.4ms +/- 4.1%     3.2ms +/- 17.4%     significant
    recursive:         10.7x as fast       34.4ms +/- 4.1%     3.2ms +/- 17.4%     significant

  crypto:              1.82x as fast       56.8ms +/- 7.0%    31.2ms +/- 6.5%     significant
    aes:               3.57x as fast       33.6ms +/- 8.1%     9.4ms +/- 7.2%     significant
    md5:               1.29x as fast       14.2ms +/- 3.9%    11.0ms +/- 8.0%     significant
    sha1:              *1.20x as slow*      9.0ms +/- 16.9%    10.8ms +/- 9.6%     significant

  date:                2.28x as fast      171.6ms +/- 2.2%    75.2ms +/- 3.9%     significant
    format-tofte:      3.46x as fast      104.4ms +/- 3.4%    30.2ms +/- 1.8%     significant
    format-xparb:      1.49x as fast       67.2ms +/- 2.4%    45.0ms +/- 5.9%     significant

  math:                *1.05x as slow*     45.4ms +/- 2.4%    47.6ms +/- 3.5%     significant
    cordic:            1.06x as fast       20.2ms +/- 2.8%    19.0ms +/- 6.5%     significant
    partial-sums:      *1.10x as slow*     18.8ms +/- 3.0%    20.6ms +/- 3.3%     significant
    spectral-norm:     *1.25x as slow*      6.4ms +/- 17.4%     8.0ms +/- 0.0%     significant

  regexp:              4.44x as fast       78.2ms +/- 12.2%    17.6ms +/- 3.9%     significant
    dna:               4.44x as fast       78.2ms +/- 12.2%    17.6ms +/- 3.9%     significant

  string:              2.26x as fast      384.0ms +/- 11.2%   170.0ms +/- 4.8%     significant
    base64:            *1.60x as slow*     11.0ms +/- 8.0%    17.6ms +/- 6.3%     significant
    fasta:             2.49x as fast       72.8ms +/- 3.9%    29.2ms +/- 7.6%     significant
    tagcloud:          2.83x as fast      102.4ms +/- 6.7%    36.2ms +/- 7.4%     significant
    unpack-code:       3.02x as fast      162.6ms +/- 17.7%    53.8ms +/- 3.4%     significant
    validate-input:    -                   35.2ms +/- 18.3%    33.2ms +/- 4.9%

September 28, 2009

Removing Adobe Drive CS4 in Windows

Filed under: howto,whining — jeffc @ 8:53 pm

So, after sitting around for more than an hour waiting for Adobe’s indecently bloated CS4 installer to finish installing Photoshop and Flash, I right-click on a file, and am rewarded with a lovely little “Adobe Drive CS4″ context option. I definitely didn’t want this, and I’m upset that when all I asked for was Flash and Photoshop two new Adobe submenus appear on my Start list, one containing only “Adobe Media Player” and another containing nine items, only two of which I asked for, plus another top-level icon for “Acrobat.com”, so Adobe sucks.

Anyway, it seems that the recommended method to remove Adobe Drive CS4 from the context menu is to open the installer and uninstall it (funny that I wasn’t asked about this the first time), but if you’re running Windows in a virtualized guest like me and don’t want to wait the ten minutes it takes Adobe to “[check your system profile]” and “[Load] Setup”, remove these two registry keys:

HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers\{C95FFEAE-A32E-4122-A5C4-49B5BFB69795}
HKEY_CLASSES_ROOT\Directory\Background\shellex\ContextMenuHandlers\{C95FFEAE-A32E-4122-A5C4-49B5BFB69795}

and you should be freed from offending entry.

Alas, Adobe Drive CS4 is still sitting around somewhere sucking up space uselessly, but we’ll leave well enough alone for now.

Joel’s “Duct-Tape Programmer” is the only programmer you should ever hire.

Filed under: business,programming — jeffc @ 7:57 pm

I’ve just finished reading Joel Spolsky’s “Duct Tape Programmers” and jwz’s response to it.

These posts strike a chord with me, especially that Spolsky spends the entirety of the article praising “The Duct-Tape Programmer” before he urges you not to try it. Mr. Spolsky should consider this situation:

I’ve just got off a job where the on-staff programmers were absolutely adamant that CakePHP be deployed in _every_ conceivable usage. The manager was brand-new, fresh out of college, with no mentionable experience. The other developer was a contracted freelancer who has never been exposed to any “decent” work (unless you count his own, which, of course, he does).

Neither one of these people know about Joel Spolsky, Jamie Zawinsky, Aaron Seigo, or almost any other important software commentator or developer, and they make very few strides toward self-improvement.

When I left this team, they were weeks behind schedule because the naive and helpless manager/developer was unable to match his task and the contracted developer’s blinding arrogance and selfish motives regularly incited rewrites (of everyone’s code, never just his own), and caused the whole system to run completely amok. What they’ve completed is horrendously slow and unintuitive.

Mr. Spolsky, when you implore your readers not to follow in jwz’s footsteps of judgment and application, is this what you envision? Because this is where it leads. Obsession with fads or hyperfocus on one area of good practice and other symptoms of programming elitism do no good to someone actually interested in developing or maintaining functional software. Both employees in the above scenario had often-prattled lines to back up their incompetence (“premature optimization”, which I, regrettably, taught them, was their favorite), but the fact is that the principles and strategies these things represent are no good without context.

No one should ever hire someone who’s not a “duct-tape programmer” as Joel defines it, because they’re not actually “duct-tape programmers”, they’re the only the competent players in the field. Good programming is all about good judgment.

Computers are fast these days, and can take a lot of crappy programming, but unnecessarily wasteful solutions do tend to add up to a noticeable detriment in any sizable application. Sometimes this is a valid tradeoff, but sometimes it isn’t; good programming is all about finding the right balance.

I can’t tell you how many hours the contracted programmer wasted debugging functions deep within the netherparts of CakePHP when a faster, better, and more suitable custom component could have been built much faster and maintained much easier. That’s an example of a bad programmer because no matter how well he knows the target platform, he’s going to regularly misapply that knowledge.

Spolsky’s description paints the duct-tape programmer as an ignoramus, a programmer who’d just as well stick to pre-1990 languages, methods, and conventions, but that’s clearly not the case with jwz, who was one of the first third-party developers for the Palm Pre. jwz, like all other good programmers, simply knows how and when to avoid cruft and how and when to leverage existing work.

So, when Joel says the “duct-tape programmer”, what he really means is the “pragmatic, profitable programmer, the only kind of programmer you should ever hire or use; a ‘good’ programmer”. These programmers do follow the changes in the field and they do play with new technologies and methods. They simply know when to experiment, when to complicate, when to simplify, and when to ship.

There’s not necessarily anything wrong with C++, Java, Flash, or any of the thousands of other tools out there, most of which were developed for a Good Reason(tm); you just have to have the judgment to know when, where, and how to deploy them such that the product will perform adequately and business needs will be met.

Do yourself a favor and pattern your next hire after jwz; get a programmer with the know-how and the wisdom, because one is useless without the other.

Powered by WordPress