Publicerad 21 september, 2010 av Johan Beronius
Förra hösten skrev jag ett program som löser Sudokus och körde det som ett enkelt benchmark-test av javascriptprestandan i de olika webbläsarna.
Nu har jag uppdaterat testresultatet för senaste versionen av de vanligaste webbläsarna och man kan lugnt konstatera att det hänt en hel del på javascriptfronten det senaste året.
Testet jag körde är samma Sudoku-kombination som förra gången. Tiden det tar att räkna fram alla möjliga lösningar på just min dator jämförs med tiden det tog i den version av respektive webbläsare som var aktuell för ett år sedan.
Internet Explorer står för den överlägset största förbättringen och är verkligen med i matchen nu. Opera har gjort ett rejält ryck och kapat sin tid till en bråkdel. Firefox har förbättrat sin tid lite men har ändå helt plötsligt hamnat efter de andra. Chrome och Safari har putsat mer marginellt på sina redan låga tider.
Uppdatering: Grafen ovan är kompletterad med värden för senaste betan av Firefox 4, beta 6, där man kan se att hastigheten tagit ett litet steg tillbaka. Däremot verkar det vara bra saker på gång eftersom den senaste ”nightly”, beta 7 pre, visar att de klippt över hälften på tiden och hamnar på par med Chrome.
På Mac OSX ser det ut så här. Där skiljer ingenting mellan Firefox 3.6 och Firefox 4.0 beta 6. Men ”nightly” beta 7 pre knappar in på sina fortfarande snabbare konkurrenter. Framförallt Chrome 6 imponerar stort med bara en halv sekund.
På mobiltelefoner går det förstås inte lika snabbt. Här blir det inte heller så mycket en jämförelse mellan olika webbläsare utan mellan olika mobilplattformar och dess hårdvara. Det kan ändå ge en liten uppfattning vad man har för javascriptprestanda att tillgå när man utvecklar webbapplikationer för en mobil jämfört med en fullstor webbläsare.
Om du klickar på grafen och kör detta test på din mobil, skriv gärna resultatet som en kommentar.
Etiketter: Benchmark, JavaScript, Prestanda
Postat i Kod, Prestanda, Programmeringsspråk, Webbutveckling | 4 kommentarer »
Publicerad 6 oktober, 2009 av Johan Beronius
MooTools är en trevlig verktygslåda som främst är tänkt för att skriva JavaScript-kod som manipulerar element på en webbsida och skapar animeringar och grafiska effekter. Därför är den starkt knuten till objekten window och document som finns i det globala kontextet när JavaScript-kod körs på en vanlig webbsida.
MooTools i Worker-kontext
Men MooTools har även hjälpmedel för att skriva objektorienterad kod samt en del utökningar och förbättringar för språket som sådant. Om man vill dra nytta av detta för kod som körs i ett annat sammanhang där window och document inte finns tillgängliga, t.ex. i en Web Worker tråd, vad gör man för att få mootools att fungera då?
En variant är att skapa mock-up objekt för att maskera det faktum att objekten inte finns, tomma skelett som bara innehåller det nödvändigaste för att mootools skall kunna laddas utan fel. Självklart ger inte detta tillgång till någon funktionalitet som är beroende av dessa objekt men övriga funktioner finns på plats.
// If we're in a worker we need to masquerade the global context and load mootools
if (self.importScripts) {
document = {
prototype: function() {},
createElement: function() {},
getElementsByTagName: function() {return []}
};
window = {
document: document,
Document: document,
Element: { prototype: function() {} },
Window: { prototype: function() {} },
addEventListener: function() {},
attachEvent: function() {},
};
self.importScripts('mootools.js');
}Skicka objekt till Workers
Eftersom Web Workers är helt isolerade från webbsidan, dvs. inte har tillgång till något delat minne, går det inte att skicka objekt till dem hur som helst. Enda sättet att kommunicera är genom att posta meddelanden som bara kan överföra strängar. Självklart kan man då serialisera objekten till JSON och skicka med dem.
Varför heter det JSON?
Vad jag då skulle vilja reflektera över är varför det kallas JavaScript Object Notation. Ett objekt är ju en sak som vet vad den är och kan göra saker själv, dvs. en datastruktur med tillhörande kod som beskriver hur den skall uppföra sig.
När man serialiserar ett objekt till en JSON-sträng försvinner alla kodreferenser, dvs. objektets metoder, kvar har man bara datastrukturen. Därför kan det tyckas vara mer korrekt att det borde kallas JavaScript Data Notation
Välsigna datastrukturer
Vad gör vi då för att kunna använda datastrukturer som blivit deserialiserade från JSON som fullfjädrade objekt? Vi kan välsigna dem tillbaka till sin klasstillhörighet genom att koppla ihop datastrukturen med metoderna från klassen igen. Därför skapar vi en en konstruktor som heter bless i basklassen för alla klasser Class som tar en datastruktur och utökar en ny instans av klassen med denna.
// Contructor that returns a new instance of this class
// extended with all properties of the given data structure
Class.prototype.bless = function(data) {
return $extend(new this(), data);
};Då kan vi sedan göra exempelvis så här:
var MyClass = new Class({
myData: "Hello, world!",
doStuff: function() {
alert(this.myData);
}
});
var myObject = new MyClass();
var string = JSON.encode(myObject);
var data = JSON.decode(string);
// data.doStuff(); <--- Not possible here
var newObject = MyClass.bless(data);
newObject.doStuff();På så vis kan man återskapa objekt som är identiska med de som skickades trots att de har blivit omvandlade till och från en ren textsträng på vägen.
Etiketter: JavaScript, JSON, mootools, Web Workers
Postat i Kod, Programmeringsspråk, Webbutveckling | Inga kommentarer »
Publicerad 1 oktober, 2009 av Johan Beronius
För moderna webbapplikationer där en större del av koden körs i webbläsaren blir det allt viktigare med bra prestanda för exekvering av JavaScript.
För att kontrollera text i formulärfält och liknande simpla uppgifter är inte hastigheten så avgörande, men vad händer om man försöker köra tyngre beräkningar? För att göra ett benchmark som testar prestandan i de vanligaste webbläsarna har jag skrivit ett program som löser Sudokus.
För att jämföra de olika webbläsarna har jag kört denna Sudoku-kombination och jämfört tiden det tar att räkna fram alla möjliga lösningar på just min dator. Resultatet är ganska häpnadsväckande, som ni kan se i grafen nedan så utklassar Safari Internet Explorer med nästan en faktor på tio-till-ett. Chrome hamnar inte långt efter och både Firefox och Opera placerar sig hyffsat bra. Och då används inte ens Web Worker-trådar som har visat sig ha potential att dubbla prestandan och ytterligare öka försprånget för alla andra webbläsare framför Internet Explorer.
Etiketter: Benchmark, JavaScript, Prestanda
Postat i Kod, Prestanda, Programmeringsspråk, Webbutveckling | 1 kommentar »
Publicerad 8 april, 2009 av Johan Beronius
I mitt förra inlägg berättade jag om en Perl-modul som vi släppt som öppen källkod. Det visade sig att denna kod ganska snabbt skulle komma till nytta. Häromdagen fick jag ett e-postmeddelande från Valmyndigheten där de berättade att de använder modulen och att den passar deras behov perfekt. De använder den för att konvertera positionen för alla vallokaler från RT90 till SWEREF99 för presentation på en karta på webben.
Modulen hittar ni här: Geo::SweGrid
Etiketter: CPAN, Perl, Positionering
Postat i Kod, Webbutveckling | Inga kommentarer »
Publicerad 25 mars, 2009 av Johan Beronius
Athega har sedan länge, ända sedan starten 1997, arbetat mycket med programmeringsspråket Perl. Vi använder oss i mycket stor utsträckning av öppna och fria mjukvaror och verktyg för de system vi bygger. Därför är även en stor del av den kod vi själva producerar befriad från licenskostnader och betraktas som ”open source” även om den kanske i vissa fall inte finns publikt tillgänglig på nätet.
Saker som går att återanvända och andra kan ha nytta av delar vi gärna med oss av. Ett exempel på detta är Perl-modulen Geo::SweGrid som används för att konvertera geografiska koordinater mellan det system som används globalt och det som används på vissa svenska kartor.
Det distribuerade arkivet för Perl-moduler heter CPAN, dit kan alla bidra med sin kod. När en modul väl finns i arkivet kan den lätt installeras på vilken dator som helst så här:
[user@host ~]$ sudo cpan
cpan shell -- CPAN exploration and modules installation (v1.9304)
ReadLine support enabled
cpan> install Geo::SweGrid
Etiketter: CPAN, GPS, Perl, Positionering
Postat i Kod, Webbutveckling, Öppen källkod | Inga kommentarer »
