September 17th, 2007
Recently, I've been spending a lot of time analyzing the speed of pure JavaScript engines, looking at how well they perform and what their particular strengths and weaknesses are. To start with, I analyzed the bleeding-edge code from:
Right now I'm only looking at pure, JavaScript-only, tests (no tests of DOM or other APIs) and am NOT looking at the speed of the browsers' native JavaScript engine implementations. (So, even though you may see a speed for a particular engine, that does not directly correlate to the speed of the JavaScript running within the browser itself. There's always a significant amount of overhead required to run JavaScript code seurely within a browser, thus the efficiency of that security layer will frequently become a deciding factor in the results.
The four engines that I picked all had complete JavaScript implementations and usable JavaScript shells (that way I could feed my tests in and have them cleanly run).
To browse the results I've pulled together a simple application that can be used to view a representation of the data from all the major JavaScript engines paired with the code from the tests which run them.
Right now the browser works fine in Firefox, is quirky in Opera and Safari, and explodes in IE (it requires canvas support). I'll finesse it into shape when I have a little more time this week.
Note: This demo uses a bunch of functionality from the new jQuery UI library, including themes, tabs, accordion, and resizables.
Tags: analysis, speed, data, javascript, ecmascript
25 Comments on 'JavaScript Engine Speeds'
July 10th, 2005
A piece of information that I've been analyzing, in my spare time, is the number of readers on this web log. How this is done can be very tricky, as there are a number of factors (people can click your RSS feed and 'view' it in their browser, but it doesn't mean that they're reading it on a regular basis). Regardless, the easiest way to figure out, approximately, how many readers you have is to count the numbers provided by news aggregators in their user agent string. Some information on common user agent formats can be found in an excellent write up on InsideGoogle.
I've also pulled together some code, from a Perl application that I'm writing in my spare time, if you're interested in tracking something like this yourself.
my %rss =
(
"Blog" =>
["/index.rdf",
"/?p=rss",
"/blog/index.rdf"],
"Links" =>
["/links/index.rdf"],
"Projects" =>
["/projects/index.rdf"]
);
my @rss_names = qw( users subscribers readers );
my %rss_count = ();
my %rss_ip = ();
sub rss {
my ( $page, $user, $ip ) = @_;
my $found = 1;
foreach my $i ( keys %rss ) {
foreach ( @{ $rss{ $i } } ) {
if ( $page eq $_ ) {
unless ( exists $rss_ip{ $i }{ $ip } ) {
my $count = 1;
foreach ( @rss_names ) {
if ( $user =~ /(\d+) $_/i ) {
$count = $1;
} elsif ( $user =~ /$_ (\d+)/i ) {
$count = $1;
}
}
$rss_count{$i} += $count;
$rss_ip{ $i }{ $ip } = 1;
}
return 0;
}
}
}
return 1;
}
In a nutshell, this is what the code is doing: Each RSS feed is analyzed, of which each feed can have multiple URLs. The URLs for the RSS feeds are specified in the first declaration:
my %rss = (
"Blog" => ["/index.rdf","/?p=rss","/blog/index.rdf"],
"Links" => ["/links/index.rdf"],
"Projects" => ["/projects/index.rdf"]
);
(This pieces of code is what I use on my weblog.) I especially like the multiple URLs to RSS feed due to mis-behaving news aggregators not following updated permanent redirects. This way I can make sure that everyone reading the same content is pulled together.
The next aspect of RSS tracking lies in figuring out if the IP of the RSS user is unique, or not. Currently, this is the only way to track users who don't use some form of a public aggregator and only pull information using some form of a desktop news application.
The main subroutine, itself, accepts three arguments. $page takes the URI of the requested page (e.g. /index.html). $user takes the user's user agent string. $ip takes the user's IP. The best way to use this subroutine is by iterating over your web server access logs (whatever form they may be in), parsing out the three pieces of information described above, and feeding it into this method.
After you're done parsing all the requested information from your logs, you now have a nice little hash of information, that will look something like this:
%rss_count = (
"Blog" => 155,
"Links" => 31,
"Projects" => 45
);
Unfortunately, you end up having to take this figures with a grain of salt, considering that users sometimes request a feed, but end up not becoming a regular subscriber. You'll probably notice that you're subscription numbers fluctuate on a day-by-day basis, this is mostly due to the fact that different numbers of people read on different days of the week (weekends are very slow reader days).
So, play around with this code, have some fun - I'm hoping to release a full stats app that I've developed (using the above code), here soon.
Tags: rss, blogs, news, aggregator, data, analysis, stats
Comment on 'Number of RSS Readers'
