Web Info & Tutorials

OpenKM is a multi-platform application for document management based on GWT, JBoss, and Jackrabbit (the content repository API).

Version 2.0 has been released, which you can test drive to see the application-style interface. The new features in 2.0 include: the previsualization of multimedia elements as images and videos, an improved an rewritten administration interface, a centralized management of templates, an exclusive area to allow users to store their private documentation, a tool for massive import and output data from ZIP files, searches by date ranks as well as translations to more languages.

However, one of the more relevant functions to mention is the indexing of the most common types of files: text, Office, Office 2007, OpenOffice, PDF, HTML, XML, MP3, JPEG, etc.

Are child selectors slower than more simple brethren? This is a question that Jon Sykes sought out data for after he read the work of Jim Barraud.

His conclusion?

The skinny is that child selectors are a major performance issue.

This seemed to make sense, but to me I needed some sort of proof rather than just being told it’s that way by someone, so over the last two days I’ve tried two approaches to see if I can replicate the issue.

The first one was rather a half-assed idea that afterwards seems fundamentally flawed as a benchmark.

So I took a new approach which does seem to return some valid and rather interesting findings, particularly regarding Safari and Firefox 3 and how they react to child selectors and performance.

The tests show that there is slow down using child selectors over direct class name declarations in IE6, IE7 and Safari 3. Safari 3 being the most impacted by child selectors. Firefox 2 has some impact, and Firefox 3 doesn’t seem to be impacted at all.

That said, this is a very extreme test, it is not often you’d have 20,000 class definitions in a single page or that all of them would use 4 levels of child selector.

Piotr Dachtera took his 64pola.pl, and created a scalable version using Comet. Dylan reports it as “a Jetty-powered Comet app that uses dojox.cometd on the client-side. It’s a solid implementation that shows chess moves in real-time, and to date is the best all-around Comet game I’ve seen that is live to the world.”

Mathieu Nouzareth then commented that Cafe.com, a Flash based gaming platform also uses Jetty and Comet techniques (compared to AMF etc).

Tom Trenka has detailed a great analysis of JavaScript performance across the various browsers. This is important work, and it reminded me of the JVM days where people tried to use pools and such… to find out that they were bad for performance as newer VM technology came out. When you try to be too tricky you can end up in a bad state as new versions try to optimize the common task, and not your trick.

Eugene Lazutkin had a great explanation on Strings in languages:

Many modern languages (especially functional languages) employ “the immutable object” paradigm, which solves a lot of problems including the memory conservation, the cache localization, addressing concurrency concerns, and so on. The idea is simple: if object is immutable, it can be represented by a reference (a pointer, a handle), and passing a reference is the same as passing an object by value — if object is immutable, its value cannot be changed => a pointer pointing to this object can be dereferenced producing the same original value. It means we can replicate pointers without replicating objects. And all of them would point to the same object. What do we do when we need to change the object? One popular solution is to use Copy-on-write (COW). Under COW principle we have a pointer to the object (a reference, a handle), we clone the object it points to, we change the value of the pointer so now it points to the cloned object, and proceed with our mutating algorithm. All other references are still the same.

JavaScript performs all of “the immutable object” things for strings, but it doesn’t do COW on strings because it uses even simpler trick: there is no way to modify a string. All strings are immutable by virtue of the language specification and the standard library it comes with. For example: str.replace(”a”, “b”) doesn’t modify str at all, it returns a new string with the replacement executed. Or not. If the pattern was not found I suspect it’ll return a pointer to the original string. Every “mutating” operation for strings actually returns a new object leaving the original string unchanged: replace, concat, slice, substr, split, and even exotic anchor, big, bold, and so on.

Tom then went on to detail the rounds that he went through:

• Round 1: Measuring Native Operations.
• Round 2: Comparing types of buffering techniques.
• Round 3: Applying Results to dojox.string.Builder.

There are a few surprises here, and Tom later concludes:

• Native string operations in all browsers have been optimized to the point where borrowing techniques from other languages (such as passing around a single buffer for use by many methods) is for the most part unneeded.
• Array.join still seems to be the fastest method with Internet Explorer; either += or String.prototype.concat.apply(””, arguments) work best for all other browsers.
• Firefox has definite issues with accessing argument members via dynamic/variables

Erik Arvidsson reminds us of the reason to use push(): IE6 and it’s really bad GC.

I look forward to the IE 8 / FF 3 results too.