Джаву хотят научить кушать меньше памяти

∞/x=∞

The new String class will store characters encoded either as ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes per character), based upon the contents of the string

Гениальностью так и прёт. Не понятно только как это поможет любителям из стран 2-го и 3-го миров работать с текстами.

There are literally several levels of Java being greedy for memory. And even if we were to live in that alternate universe where Java would not have high memory consumption, it would still be greedy for memory.

Не понятно только как это поможет любителям из стран 2-го и 3-го миров работать с текстами.

Будто кого-то волнуют проблемы недолюдей.

Я как раз сейчас хочу обсудить это в mailing list. По сути, можно в флаге указывать однобайтовую codepage определенной страны 3-го мира. Но китайцам с прочими японцами не судьба, да.

Гениальностью так и прёт.

Лучше хоть что-то, чем ничего. Тем более джава в основном это дотком.

Будто кого-то волнуют проблемы недолюдей.

+1

Будто кого-то волнуют проблемы недолюдей.

А ты че, себя людьми чтоли считаешь, говно на палочке?

Будто кого-то волнуют проблемы недолюдей.

Зачем же так грубо высказываться о ява разработчиках и пользователеях их продуктов. Не все же этим занимаются от хорошей жизни.

Лучше хоть что-то, чем ничего

Если это идиотизм из-зи прокрастинации, то лучше ничего.

Хорошее решение. UTF-8 был бы ещё лучше, если бы его использовали с самого начала.

А как строками манипулировать в multi-byte кодировке? А в Qt внутренний формат какой?

А O(1) random access ты как обеспечишь с utf-8?

А O(1) random access ты как обеспечишь с utf-8?

А как его обеспечить с utf-16? Это тоже мультибайтовая кодировка. Вообще «random access» для текста практически не нужен.

А как строками манипулировать в multi-byte кодировке?

С какой конкретно манипуляцией возникают проблемы?

А в Qt внутренний формат какой?

UTF-16

Ок. Я думал в жабе ucs-2.

А O(1) random access ты как обеспечишь с utf-8?

Случайный доступ к чему именно нужно обеспечить? И в каких задачах это требуется?

Мде... вопросов больше не имею :)

UCS-2 это устаревшая кодировка. UTF-16 это её надмножество, введённое, когда стало понятно, что в 65000 символов все символы юникода не влезут.

те самые смайлики с неграми не влезли

Случайный доступ к чему именно нужно обеспечить?

К символам строки, по индексу.

На www бекенде или кому с текстами работать очень пригодится.

Кому на www «бекенде» или «с текстами работать» очень бы пригодился стандартный аналог GNU gettext. Ибо то, что сейчас есть - просто убожество (да, я в курсе что gettext для жабы тоже есть).

К символам строки, по индексу.

А что ты понимаешь под символом строки? unicode codepoint? К нему не будет случайного доступа, как его нет практически ни в одном языке программирования сейчас. Если твой алгоритм требует такого доступа, создай массив 4-байтовых чисел и заполни его codepoint-ами. Правда скорее всего тебе нужен доступ к графемам, а не символам. Например «ë» это 2 символа: комбинирующий «¨» и «e». Но для пользователя это один знак. К ним тоже не будет случайного доступа, потому что эти графемы в общем случае могут занимать произвольное число байтов или codepoint-ов. Если надо — заводи массив строк и заполняй их. Или массив указателей на исходную строку.

Только ты не ответил,

в каких задачах это требуется?

в каких задачах это требуется?

Не знаю. Но charAt() зачем-то зделали.

Не знаю. Но charAt() зачем-то зделали.

Её сделали много лет назад ещё до появления юникода, как стандарта. Сегодня эта функция бесполезна. В современных языках (Rust, Swift) подобной функции уже нет.

На самом деле один из девелоперов и перформанс-инженеров этой фичи Алексей Шипилёв - вполне себе из России. И их анализ показал, что часто в продакшене в памяти лежат однобайтовые строки, и в среднем уменьшение потребления памяти 15%.

помоему это уже было в каких-то сборках 6-ки или 7-ки, но потом оно не прижилось. Еще раз решили попробовать?

... в среднем уменьшение потребления памяти 15%.

Кризис, что ли, больше не позволяет кормить яву железом что на спичках начали экономить?

Вопрос ведь не только в том, чтобы поставить больше планок памяти. Чем больше хип, тем дольше времени требуется GC чтобы его обойти. Ну и 15% весьма неплохо, для нашего приложения это освободит почти 5 гигабайт памяти.

Кризис, что ли, больше не позволяет кормить яву железом что на спичках начали экономить?

http://cr.openjdk.java.net/~shade/density/state-of-string-density-v1.txt

«In other words, latin version is ~20% faster while allocating ~30% less garbage.»

Это не спички, а серьезный буст перформанса.

Время обхода зависит от количества объектов, а не их размера. Выигрыш в производительности будет от того, что строчки будут охотней помещаться в кеши процессора и будет меньше обращений в память.

Хорошо вы живете, если 15% для вас это «спички».

charAt() ... Сегодня эта функция бесполезна.

И как теперь пишется табулированный вывод? Наподобие такого:

     ААА|  23
 тест ок|  11

И в каких задачах это требуется?

Чтение файла в формате fixed-width text

Не влетит. Инфа 194%

ЗЫ Не джавист.

Универсально — никак. Ты же не знаешь ширину шрифта, поддерживаемые им символы, в Java нет такого API. Например есть символ эмодзи «принцесса». Он занимает 2 «char-а». К нему ещё могут быть модификаторы, например «чёрная принцесса». Это ещё +2 «char-а». Причём на одной системе шрифт и рендеринг поддерживает это всё и все эти 4 char-а будут выведены, как один символ. На другой системе будут 4 квадратика.

Поэтому нужен тебе табулированный вывод — пиши в HTML, например. Браузер уже выровняет всё, как надо.

Ну или ограничить себя ASCII, скажем. Тогда некоторые проблемы решаются. Но надо понимать, что это уже будет не универсальное приложение.

Ты же не знаешь ширину шрифта, поддерживаемые им символы

Табулированный вывод существует только в моноширинном шрифте. Или таковых тоже больше не существует?

Табулированный вывод существует только в моноширинном шрифте. Или таковых тоже больше не существует?

Существуют. А как ты выведешь что-либо моноширинным шрифтом? У пользователя в терминале стоит Comic Sans, например. Но моноширинность шрифта это полбеды и к Java не относится.

Не знаю. Но charAt() зачем-то зделали.

в swift такого нет, а если apple этого не реализовали, значит оно никому не нужно

недочеловеки могут страдать дальше

У пользователя в терминале стоит Comic Sans, например.

Вообще-то это может быть и графическая программа.

Например, Emacs.

Но моноширинность шрифта это полбеды и к Java не относится.

В Java charAt есть и работает. И length там в символах, а не байтах как в Rust.

В Java charAt есть и работает. И length там в символах, а не байтах как в Rust.

Блажен кто верует.

import java.util.*;
import java.lang.*;
import java.io.*;

class Main
{
	public static void main (String[] args) throws java.lang.Exception
	{
		System.out.println("привет".length());
	}
}

выводит 6, как и должен.

package test;

public class Test {
    public static void main(String[] args) {
        String str = "i\u0302nghet\u0327ata\u0306";
        System.out.println(str);
        System.out.println(str.length());
    }
}

Выводит

îngheţată
12

Грубо говоря в Rust-е length это количество байтов в кодировке UTF-8. В Java length это половина количества байтов в кодировке UTF-16. Принципиальной разницы нет, только кодировка другая.

хотя в слове îngheţată 9 букв.

Так у тебя в строке не оно. Просто print нормализацию делает.

Вот в Racket наглядно

> (define s "i\u0302nghet\u0327ata\u0306")
> s
"îngheţată"
> (string-length s)
12
> (string-normalize-nfc s)
"îngheţată"
> (string-length (string-normalize-nfc s))
9

Принципиальной разницы нет, только кодировка другая.

Считаю верным вариант «четверть количества байт в кодировке UCS-4»

Это если строку можно нормализовать. А есть буквы, код которых в UTF-16 не вмещаются в 2 байта и они представляются в виде суррогатной пары, как ни нормализуй.

почеуб не запилить utf-8

Вот например символ http://unicode-table.com/en/10330/

У него код U+10330

В UTF-16 это 4 байта: D8 00 DF 30

В UTF-32 это тоже 4 байта: 00 01 03 30

Этот пример расходится с твоей трактовкой «четверть количества байт в кодировке UCS-4».

Аминь!

В UTF-16 это 4 байта: D8 00 DF 30

В UTF-32 это тоже 4 байта: 00 01 03 30

А при чём тут UTF-16? В UCS-4 это один символ (сам пишешь U+10330).

Этот пример расходится с твоей трактовкой «четверть количества байт в кодировке UCS-4».

Ничуть. Этот символ, как и любой другой, в UCS-4 занимает ровно 4 байта.