Hezké shrnutí. Ještě dneska si pamatuju na to pozdvižení, když RedHat zvolil do své distribuce UTF-8 jako výchozí kódování. Dneska je cokoliv jiného sebevražda :-)
Ten první příklad bude spíš klasické x86, nikoliv x86_64. I když za předpokladu, že adresa řetězce bude ve spodních 32 bitech (což asi bude), by mohl spíše náhodou fungovat i na x86_64. Nejsem si jistý, jestli je podporováno int $0x80 místo sysenter... Řetězec by běžně umístil překladač do sekce ".text".
Myšlenka v python 3.3 je zajímavá, ale když budu generovat nebo číst nějaké XML a ukládat do string bufferu, tak kvůli pozdravu českého uživatele bude celá anglická stránka čtyřikrát (či dvakrát) větší. V tomto by python 2 s UTF-8 šetrnější. IMHO by spíš mělo smysl udržovat UTF-8 a v případě potřeby náhodného přístupu explicitně vytvořit UCS-4 kopii.
UTF-8 je genialni na prenos, aspon z naseho pohledu, Asiate to vidi jinak :), ale interne se s nim pracuje blbe, protoze se musis "trefovat" do znaku pri kazdem indexovani nebo slicingu. Ale ty myslis to, ze proste defaultne bude pouzito UTF-8 a bude se provadet nejake copy-on-index? Hmm jako je to zajimave, ale asi by to chtelo benchmarky.
Asiatům je to jedno, bo v naprosté většině případů vidí dva byty jak v UCS-2, tak UTF-8 :-) A pořád je tam dost věcí (HTML, JavaScript, JSON, kódy v localization), které budou z velké části ASCII, takže i tak ušetří.
K druhé části - spíš mít dva různé typy pro různé účely. I to málo situací, kde se používá .charAt(), povětšinou stačí implementace po bytech, bo se třeba jen porovnávají dva řetězce, bere se substring, ale na nějaký kód apod (typicky nějaký parser, který při nalezení speciálního znaku (což je obvykle ASCII) vezme předchozí sekvenci bytů a vyrobí z něj String). Těch situací, kdy je skutečně vyžadován random access k char (codepoint) dle indexu, je jako šafránu. Takový UcsString by se případně mohl cachovat v rámci původního Utf8 String, i když pochybuju, že by to mělo dramatický přínos (s výjimkou GUI aplikací, ale tam ty řetězce obvykle nebývají enormně dlouhé).
"Asiatům je to jedno, bo v naprosté většině případů vidí dva byty jak v UCS-2, tak UTF-8 :-)"
No to právě ne, do těch dvou bajtů nacpeš jen 128+1920 = 2048 znaků. Jsou tam bohudík česká nabodeníčka, azbuka, alfabeta, hebrejština, ale CJK tam nejsou. Na tu jsou v UTF-8 potřeba tři bajty. Takže je to bolí dost, protože u nás je to sem tam dvoubajtový znak s nabodeníčkem (2 bajty), jinak většina textu má znaky na jeden bajt. Oni mají prakticky konstantně 2 bajty/znak (proto nebyli s UCS a UTF moc nadšeni a dost dlouho si drželi svoje kódování).
PS: předchozí odstavec má 453 bajtů v jednobajtovém kódování (ISO-8859-2) a 484 bajtů v UTF-8, což je v pohodě.
Máš pravdu, ten příklad je pro x86, už jsem to opravil.
Mimochodem ty příklady s hello world mám připravené pro víc architektur, takže v případě zájmu sosejte na https://github.com/tisnik/presentations/tree/master/assembler/03_gas_hello_world (pro PPC a s390 to vytvorili guruove na tu platformu, ja bych to nedal :-)
"Myšlenka v python 3.3 je zajímavá, ale když budu generovat nebo číst nějaké XML a ukládat do string bufferu, tak kvůli pozdravu českého uživatele bude celá anglická stránka čtyřikrát (či dvakrát) větší"
Bude to dvakrát větší (viz ten příklad s "ěščř...." na konci článku), ale například pro různé webservicy, kde se přenáší mraky datových XML nebo JSONy to je fajn, tam je to většinou čisté ASCII. Dtto SVG a podobné XML implementace.
Pokud ty data obsahují třeba jména nebo adresy (což obvykle obsahují), tak to bude plýtvat. Pokud půjde jenom o nějaké měření, souřadnice apod., tak ano - tam to bude ASCII.
Na druhé straně je pravda, že chytré implementace budou nejspíš serializovat rovnou do nějakého UTF-8 byte stream, nikoliv char stream či string. Viz třeba Jackson, který má parsery pro byte array, byte stream, char stream atd. (a kde ty první dva jsou dvakrát rychlejší než poslední zmíněný :-) ).
To je pravda, určitě to na vstupu/výstupu takto bude. Ale když si představíš, jak například nějaká aplikace zpracuje vstupní JSON, který dostane z web servicy:
vstup -> obrovský řetězec (tady se může plýtvat, záleží na knihovně) -> parsing -> (teď se klidně na původní řetězec může pustit GC) -> slovník (slovníků/polí)
A u toho slovníku ty "chytré řetězce" dost pomůžou, protože můžeme dostat něco takového:
{ "firstName" : "Méďa",
"surname": "Béďa",
"comment": "pije ",
"validated": True,
"ID": 42}
Takže samozřejmě hodnoty budou muset být v UCS-2 nebo u nějakých paznaků co tam uživatel dá v UCS-4 (kupodivu to má nízký kód), ale minimálně u klíčů to bude Latin-1 (předpokládáme příčetného programátora :-)
PS: čistě teoreticky ten původní string nepůjde na GC, pokud nějaká knihovna "optimalizuje" substring() tak, že se vrací jen reference někam doprostřed původního pole.
Ok předchozí příspěvek měl za "pije " znak http://www.fileformat.info/info/unicode/char/2615/index.htm dtto v poznámce (kupodivu to http://www.fileformat.info/info/unicode/char/2615/index.htm má nízký kód). Omlouvám se, redakční systém asi nepoužívá Unicode :-)
Jasně, u těch výsledných hodnot je to jasné, a tam to může mít smysl (*), hlavně to není tak drahé.
Já měl na mysli ten původní serializovaný řetězec, ale to se spíš týká situací, které z principu optimalizované nejsou, takže je to jedno (tedy načíst všechno do řetězce a potom deserializovat). Pokud ten deserializátor umí pracovat přímo s byte streamem, tak to nic navíc nestojí.
* - tedy, ono obvykle stejně nemá, neboť hodnota se přečte a pak se jenom předá dál (do databáze či opačným směrem, obvykle opět jako UTF-8). V tomto směru by pořád dával smysl spíš explicitní random access UCS-4 string.
Jen mozna doplnim, ze kdyz nekdo bude implementovat webove forum, twitter v.4.0, mozna i ticketovaci system, tak mu asi budou retezce "podat" do UCS-4: https://stackoverflow.com/a/18477578
jako by nestacily emoticony :)