Die Verwendung von selten zutreffenden Spezialfällen als Optimierung zu verkaufen ist ziemlicher Blödsinn. Es gibt außer den ASCII Erfindern niemanden, der auch mit Latin1 als Zeichensatz auskommt.
Programmieranfänger sollten nicht mit Artikeln gelobt, sondern auf den Unfug von nicht brauchbaren Einschränkungen hingewiesen werden.
Hast du den Artikel und/oder die Quelle nicht gelesen? Selbst bei nicht-westlichen Sprachen lassen sich im Durchschnitt immer noch mehr als die Hälfte der Zeichen als Latin1 kodieren.
Auf den ersten Blick vielleicht aber bei UTF-8 sind Stringoperationen prinzipbedingt sehr aufwändig. Bei latin1 oder UTF-16 kannst Du einzelne Zeichen direkt über einen eindeutigen Index ansprechen. Bei UTF-8 geht das nüscht. Oder die Anzahl der Zeichen ermitteln; bei latin1: bytes = Anzahl der Zeichen. Bei UTF-16: bytes / 2 = Anzahl der Zeichen. Bei UTF-8 musst Du schon den ganzen Bums parsen, um die Antwort zu erhalten.
>UTF-16 kannst Du einzelne Zeichen direkt über einen eindeutigen Index ansprechen Nein. Geht nicht. Richtiges UFT-16 kann 16 ODER 32 Bit nutzen. Ist nur so, dass viele APIs (unter anderem auch die standartisierte JavaScript API) das falsch machen und UTF16 als UCS2 auffassen, so dass man da die löchrige Abstraktion hat, wo man für manche Zeichen zwei Escapierliterale braucht und streng genommen seine eigene Längenermittlung drüber legen müsste.
Da dies aber überraschend viele falsch machen, kann man das ignorieren wie ein Weltmeister.
Wie soll das gehen? Zerlegst du einen String in mehrere Teilstrings mit möglicher Latin1 Kodierung und den Rest in UTF-16. Möchtest du jedes Zeichen auf ein latin1 Equivalent prüfen. Dauert das lange?
Die Javascriptengine verarbeitet Strings generell schlecht, egal mit wie viel Speicher. Das ist keine tolle Verbesserung.
Zum Vergleich kannst du dir die Geschwindigkeit von Perl anschauen. Da sind Welten dazwischen.
Ließ doch einfach den Artikel oder die Quelle da wird es dir genau erklärt. Falls du das Verfahren, den Performanzgewinn und/oder die Speichereinsparungen in Frage stellst; der Patch ist öffentlich und du kannst es gerne selbst verifizieren.
Die Verwendung von selten zutreffenden Spezialfällen als Optimierung zu verkaufen ist ziemlicher Blödsinn. Es gibt außer den ASCII Erfindern niemanden, der auch mit Latin1 als Zeichensatz auskommt.
Programmieranfänger sollten nicht mit Artikeln gelobt, sondern auf den Unfug von nicht brauchbaren Einschränkungen hingewiesen werden.
latin1 kodiert doppelt so viele Zeichen als ASCII. Es deckt nicht nur den ASCII-Raum ab sondern zusätzlich auch Westeuropa.
Kleiner Denkanstoß. Kyrillische und griechische Zeichen sind sehr westeuropäisch und nicht mehr verfügbar.
Kleiner Denkanstoß: latin1 ist die Westeuropäische Zeichenkodierung aus ISO 8859.
Kleiner Denkanstoß. Kyrillische und griechische Zeichen sind sehr westeuropäisch und nicht mehr verfügbar.
latin1 kodiert doppelt so viele Zeichen als ASCII. Es deckt nicht nur den ASCII-Raum ab sondern zusätzlich auch Westeuropa.
Hast du den Artikel und/oder die Quelle nicht gelesen? Selbst bei nicht-westlichen Sprachen lassen sich im Durchschnitt immer noch mehr als die Hälfte der Zeichen als Latin1 kodieren.
Und genau dafür wäre UTF-8 optimal gewesen.
Aber solange man es nicht selbst kontrolliert kann man dem Autor des Patches einfach nur glauben oder nicht. Daher: egal
Hoffen wir nur, daß es keine Nebenwirkunge gibt.
> Und genau dafür wäre UTF-8 optimal gewesen.
Auf den ersten Blick vielleicht aber bei UTF-8 sind Stringoperationen prinzipbedingt sehr aufwändig.
Bei latin1 oder UTF-16 kannst Du einzelne Zeichen direkt über einen eindeutigen Index ansprechen. Bei UTF-8 geht das nüscht.
Oder die Anzahl der Zeichen ermitteln; bei latin1: bytes = Anzahl der Zeichen. Bei UTF-16: bytes / 2 = Anzahl der Zeichen. Bei UTF-8 musst Du schon den ganzen Bums parsen, um die Antwort zu erhalten.
>UTF-16 kannst Du einzelne Zeichen direkt über einen eindeutigen Index ansprechen
Nein. Geht nicht. Richtiges UFT-16 kann 16 ODER 32 Bit nutzen.
Ist nur so, dass viele APIs (unter anderem auch die standartisierte JavaScript API) das falsch machen und UTF16 als UCS2 auffassen, so dass man da die löchrige Abstraktion hat, wo man für manche Zeichen zwei Escapierliterale braucht und streng genommen seine eigene Längenermittlung drüber legen müsste.
Da dies aber überraschend viele falsch machen, kann man das ignorieren wie ein Weltmeister.
Ein Zeichen in UTF-16 kann mehr als 2 Bytes haben!
Abgesehen davon ist der Overhead von UTF-8 Operationen zu latin1 sehr gering.
Wie soll das gehen? Zerlegst du einen String in mehrere Teilstrings mit möglicher Latin1 Kodierung und den Rest in UTF-16. Möchtest du jedes Zeichen auf ein latin1 Equivalent prüfen. Dauert das lange?
Die Javascriptengine verarbeitet Strings generell schlecht, egal mit wie viel Speicher. Das ist keine tolle Verbesserung.
Zum Vergleich kannst du dir die Geschwindigkeit von Perl anschauen. Da sind Welten dazwischen.
Ließ doch einfach den Artikel oder die Quelle da wird es dir genau erklärt. Falls du das Verfahren, den Performanzgewinn und/oder die Speichereinsparungen in Frage stellst; der Patch ist öffentlich und du kannst es gerne selbst verifizieren.
Vielen Dank für die Recherche nach den Ursachen der Geschwindigkeitsvorteile. Die Angaben vermisste ich auf anderen Seiten.