Neue Benchmarks

Permanent Link: Neue Benchmarks 9. Januar 2009 Comment keine kommentare

Dromaeo hat vor kurzem ein neues Testverfahren eingeführt. Statt der benötigten Zeit für die Tests, wird nun gemessen, wie viele Durchläufe durchschnittlich pro Sekunde in einer fest definierten Zeit erreicht werden. Das macht die ganze Sache langwieriger, aber auch genauer und sagt wesentlich mehr über die Leistungsfähigkeit einer Javascript Engine aus.

Statt auf zwei unterschiedlichen Systemen zu messen, habe ich nun unterschiedliche Benchmarks gewählt: Dromaeo Javascript Test (Mozilla.org), SunSpider Javascript Test (Webkit-Team) und V8 Javascript Test (Google).

Testergebnisse

Testsystem: Intel Core 2 Duo E8400, 2 GB RAM, Windows XP SP 3

Ein Bild sagt mehr als 1.000 Worte. Chrome deklassiert alle anderen Browser, nur im hauseigenen V8-Test ist das aktuelle Webkit Nightly Build einen Tick schneller. Wie üblich sind die  Entwickler-Versionen ihren aktuellen Final-Kollegen deutlich voraus, und die Javascript-Leistung des Internet Explorers, sofern er sich überhaupt testen lies, ist ein schlechter Scherz.

Ein blamables Ergebnis für Microsoft, das mit dem IE 8 auch nicht großartig besser werden wird. Wenn man sich in Redmond angesichts solcher vernichtenden Benchmarks nicht endlich im Zugzwang sieht, sind sie entweder blind und/oder blöd. Google treibt die Entwicklung mit großen Schritten voran, während nur Webkit bzw. Apple halbwegs mithalten kann. Mozilla.org und Opera müssen sich sehr anstrengen, um wieder Anschluss zu finden.

Und Microsoft? Tja, ich sehe nur zwei Möglichkeiten: den ganzen alten IE-Quellcode öffentlich verbrennen und komplett neu schreiben, oder man setzt in Zukunft auf Webkit/Squirrelfish bzw. Webkit/V8 oder Gecko/Tracemonkey.

Sapphire

Permanent Link: Sapphire 29. Dezember 2008 Comment keine kommentare

Wie schon angekündigt, habe ich mit dem Umstieg auf Netbeans begonnen, Sapphire komplett neu zu schreiben. Der eigentliche Kern ist nahezu fertig und die ersten Module in Arbeit – ging alles wesentlich schneller als erwartet. Daher werde ich Ruby nicht mehr weiter entwickeln und die bestehenden Module umschreiben.

Dinge, wie die Mandanten-Fähigkeit noch in Ruby zu integrieren, obwohl sie im Sapphire-Kern schon implementiert sind, ist sinnlos. Außerdem ermöglicht es die neue Struktur wesentlich schneller und besser, Änderungen am Hauptsystem vorzunehmen. Das Portieren der Ruby-Module sollte relativ schnell und unproblematisch laufen.

Die wichtigsten Unterschied zwischen Ruby und Sapphire:

  1. Sapphire ist durchgängig objektorientiert, soweit es PHP 5 ermöglicht.
  2. Es werden ausschließlich Prepared SQL Statements über MySQLi oder PDO unterstützt.
  3. Die Fehler-Verwaltung läuft komplett über Exceptions (SPL und eigene).
  4. Bessere und nun vollständige Implementierung des MVC-Patterns.
  5. Alle Singleton-Patterns wurden entfernt.
  6. Mandantenfähig von Anfang an.
  7. Abstraktionsebene aller Superglobals.
  8. Alle assoziativen Arrays wurden durch Instanzen der Klasse Data ersetzt.
  9. Kleinere Änderungen an der Datenbank, u.a. für die Mandantenfähigkeit. (Ein Import-Script wie von Version 1 auf 2, ist nicht nötig.)

Insgesamt bin ich mit bisherigen Stand sehr zufrieden. Vieles ist im Vergleich zu Ruby einfacher geworden, ganz besonders der Modul-Manager – bei gleichem Funktionsumfang braucht er nur knapp die Hälfte des Quelltexts. Es ist nun wesentlich einfacher, zu überprüfen, ob ein Modul schon geladen ist und an dessen Funktionen heran zu kommen. Zusammen mit einem zukünftig implementierten Observer-Pattern und der Factory des Kerns, ist das die neue Modul-Schnittstelle.

Ruby Alpha 3

Permanent Link: Ruby Alpha 3 14. September 2008 Comment keine kommentare

Änderungen gegenüber der Alpha 2:

  • Klasse Config:
    1. Methode delVar() entfernt
    2. Methode delete() hinzufügt:
      Vereinheitlicht das Namensschema und ist in der Lage mehrere Konfigurationsvariablen auf einmal zu löschen.
    3. Magische Methode __toString() implementiert.
      Gibt alle gespeicherten Konfigurationsvariablen mittels print_r() zurück.
    4. Magische Methode __get() gibt nun eine Fehlermeldung zurück, wenn auf eine nicht verfügbare Konfigurationsvariable zugegriffen wird.
    5. Konfigurationsvariablen ScriptName, ScriptDir, ScriptRoot, ScriptURL, TemplateDir, TemplateURL, TemplateName, TemplateDateFormat, TemplateTimeFormat und TemplateDateTimeFormat wurden in die Unterobjekte script und template der Klasse Data zugeorndet. Die Präfixe Template und Script entfallen. Außerdem beginnen die Eigenschaften alle mit Kleinbuchstaben.
  • Klasse MySmarty:
    1. Es ist nicht länger notwendig, die Smarty-Methoden assign() und assign_by_ref() zu verwenden, um Smarty Variablen zuzuweisen. Stattdessen wird über die magischen Methoden __get() und __set() dem Smarty-Objekt der entsprechende Wert übergeben.
    2. Magische Methoden __get(), __set(), __isset() und __unset() implementiert.
      Ermöglichen og. Vereinfachungen, um Smarty mit Variablen zu füttern.
  • Vereinheitlichtes Namensschema aller Konfigurationsvariablen entsprechend og. Änderungen zu Kleinbuchstaben am Namensbeginn.
  • Vereinheitlichte Klassennamen im Core-System.
  • Datenbankschnittstelle über PDO hinzugefügt, Ausnahmen werden über die Klasse PDOException statt DbException gehandhabt.
  • Die verfügbaren Datenbankschnittstellen MySQL, MySQLi und PDO lassen sich über die Konfigurationsdatei anwählen.
  • Markup-Vereinfachungen im Standard-Layout
  • Update auf Smarty 2.6.20 und jQuery 1.2.6
  • Anpassungen aller Klassen und Templates an das neue Namensschema und Smarty-Variablen-Handling.
  • Funktion json_encode() wird hinzugefügt, falls PHP 5.2 ohne JSON-Erweiterung kompiliert wurde.
  • Grundsätzliche Funktionalität, um falsch als Spam oder Ham erkannte Kommentare an Akismet zu melden.
  • Weitere kleine Optimierungen und Vereinfachungen der Core- und Modul-Klassen.

Geplante Änderungen bis zur ersten Beta-Version:

  • Wegfall der normalen MySQL-Schnittstelle und Unterstützung für MySQL 4.1.
  • Absicherung über vorbereitete SQL-Abfragen mittels der Methode prepare() von MySQLi bzw. PDO.
  • Namespaces für den Core und die Module, sofern PHP 5.3 verfügbar ist.
  • Admin-Bereich für Kategorien/Tags, Kommentare, Bilder, Texte und Konfigurations-Verwaltung.
  • Neues Tag- und Kategorie-Handling im Admin-Bereich.
  • Spam-Schutz ohne Akismet und Captchas.
  • Module Texts und Images implementieren.
  • Multi-Weblog-Unterstützung über mehrere Domains hinweg.
  • json_encode() durch Zend_Json_Encoder::encode() ersetzen.

JSON

Permanent Link: JSON 15. April 2007 Comment keine kommentare

Nein, da fehlt kein a, auch wenn es wie der Name Jason ausgesprochen wird. Die Abkürzung steht für JavaScript Object Notation und ist ein relativ unkompliziertes Datenformat, das für Mensch und Rechner gleichermaßen lesbar ist.

So what? Das ist XML auch, allerdings produziert es bei weitem weniger Overhead. Viel wichtiger ist allerdings, dass es sich per eval() einfach in ein JavaScript-Objekt verwandeln lässt.

Im Klartext: man kann in JSON codierte Daten, z.B. aus einem PHP-Script problemlos an JavaScript übergeben und damit ohne großen Aufwand arbeiten. Ideal für den Datenaustausch zwischen Server und Client bei AJAX -Applikationen.

Sicher ist der Hype um Web 2.0 bzw. AJAX groß, und einige verschmähen das Thema. Viele sind sich leider nicht im Klaren darüber, dass in diesem Fall weniger wirklich mehr ist. Dennoch kann man mit gezielten Einsatz tolle Sachen bewerkstelligen und die Bedienung erleichtern.

Daher kann ich das Theman JSON jedem ans Herz legen, der seine Scripts mit AJAX aufwerten will.

MCW.blog (ab 1.0.1) setzt JSON in Verbindung mit AJAX beispielsweise im Admin-Bereich ein: während man einen Eintrag oder Text eingibt, kann dort Kategorien bzw. Tags einfügen, ohne eine weitere Seite öffnen oder die aktuelle neu laden zu müssen.