В холиварах MS Office против TeX я пришёл к такому пониманию: чтобы делать хорошие документы в обеих системах, надо многому учиться. Но чтобы делать плохие документы, в MS Office учиться не надо вообще, а в TeX всё равно надо. Иначе даже не будешь знать, с какой стороны подойти. Таким образом TeX отсекает пользователей, которые не хотят учиться, и среднее качество TeX-документов выше. MS Office располагает к отношению «сейчас куда-нибудь кликну, и что-нибудь получится», а надо, как и с TeX, читать документацию. Из-за этого большинство проблем с MS Office. Но благодаря этому же он больше распространён.
Возможно, вы не умеете просто пользоваться MSO? Формулы вставляются легко и непринуждённо. Можно вообще всё с клавиатуры делать. Другое дело, что на целевой системе может не быть специальных шрифтов с символами из формул, а автор презентации не догадался эмбеддить специальные шрифты прямо в презентацию. Тогда и получится тот ужас, что на верхнем слайде.
У меня нет аккаунтов в социальных сетях, поэтому эти кнопки для меня бесполезны. Разве что мог бы нажать «поделиться в ЖЖ», но я в ЖЖ всё равно не пишу, так что не вижу смысла.
Можно сочетать с псевдослучайным алгоритмом: время от времени подменять его seed на число, полученное с сервера (это можно делать асинхронно, тормозить не будет). Если заменить цепочку истинно случайных чисел на набор коротких случайных цепочек псевдослучайных чисел то, возможно, это устроит пользователя. Хотя, конечно, зависит от приложения.
По-моему, разумно добавить подкласс класса java.util.Random. Вам потребуется только переписать защищённый метод next. Ну, разумеется, seed будете игнорировать, да readObject/writeObject станут бесполезны. Зато ваш класс можно будет подсовывать тем, кто уже пользуется java.util.Random. Ну и появятся автоматом приятные фишки типа nextGaussian().
А если даже отвлечься от UseCompressedStrings, то извлечение строк будет копировать буфер (то же касается автоматического формирования строк, как в комментарии от TheShade): каждый get() будет создавать не только объект String, но и ещё новый char[].
4Мб лишь пример. Если же речь о 4Гб то, конечно, стоит загружать данные по частям, но разве вам не будет приятно узнать, что вы можете загрузить существенно больше данных одновременно, снижая частоту подгрузок? :-)
Интересно, не знал про такой метод. Видимо, потому что никогда не создаю переменных типа ArrayList, пользуясь только теми методами, что объявлены в интерфейсе List. Ну да, trimToSize будет эффективнее, если случится так, что текущий размер списка совпадает с числом элементов. Если нет, то разница минимальна, но мой способ подойдёт для любой реализации списка :-)
За статью спасибо, интересно. Skip-list'ы сразу вспомнились…