Монстр прекрасно работает, а люди которые им пользуются даже не знают о том, что скрыто за RESTfull API.
Узкое место в данном случае — архитектура. Но с изменениями архитектуры прийдётся смириться с множеством изменений производительности или недоступности некоторых операций.
В итоге прошла волна оптимизации, которая дала время более детально обдумать и обсудить в команде возможные изменения.
Кодеки не сторят данные в память (кроме буфферизации конечно), так что и Си используют не по причине памяти. Для них больше важна скорость, которая достигается с помощью нативных операций.
Хотя в чем-то я с Вами согласен. В любом случае в проекте есть модули написанные на С++, так что не без этого.
Правда в том же разделе мы видим, что произведена оптимизация для работы с массивами boolean, которые преобразуются в массив байт, что даёт прирост доступной памяти в 4 раза.
Спасибо за критику — за ней и пришел. Критика стимулирует рост.
Как Вы думаете, сколько людей прочли Эккеля прежде(!), чем садиться программировать что либо? Сдаётся мне всё приходит с опытом. Надеюсь, для кого-то эта статья превратиться в стимул или опыт.
Извините, просмотрел наискосок. Собсственно, об этой оптимизации я говорил в контексте boolean[], но если JVM умеет оптимизировать даже разрозненные переменные — только плюс ей, у меня так не вышло.
Данный проект достался мне в наследство, но я вам скажу, ведёт он себя более стабильно и предсказуемо, чем многие другие. Рефакторинг, конечно назрел, но не думаю, что это кардинально скажется на описанных параметрах, поскольку платиться временем подготовки ради использования меньшего объема памяти никто пока не согласен.
Есть и точки сохранения и модульность — здесь всё хорошо (хотя и не отлично). Т.е. система даже больше чем описана в оригинальном посте, а описание идёт конкретного модуля.
Таких проектов много. Всё зависит от того, что вам важнее — память или быстродействие. Для нас более приоритетным на данный момент есть быстродействие.
5 часов — не совсем чистый запуск, а подготовка данных (импорт) + препроцессинг.
Узкое место в данном случае — архитектура. Но с изменениями архитектуры прийдётся смириться с множеством изменений производительности или недоступности некоторых операций.
В итоге прошла волна оптимизации, которая дала время более детально обдумать и обсудить в команде возможные изменения.
Хотя в чем-то я с Вами согласен. В любом случае в проекте есть модули написанные на С++, так что не без этого.
Как Вы думаете, сколько людей прочли Эккеля прежде(!), чем садиться программировать что либо? Сдаётся мне всё приходит с опытом. Надеюсь, для кого-то эта статья превратиться в стимул или опыт.
А косяки есть везде, куда ж без них.
Данный проект достался мне в наследство, но я вам скажу, ведёт он себя более стабильно и предсказуемо, чем многие другие. Рефакторинг, конечно назрел, но не думаю, что это кардинально скажется на описанных параметрах, поскольку платиться временем подготовки ради использования меньшего объема памяти никто пока не согласен.
Есть и точки сохранения и модульность — здесь всё хорошо (хотя и не отлично). Т.е. система даже больше чем описана в оригинальном посте, а описание идёт конкретного модуля.
Как я и говорил всё зависит от соотношения
цена/качествопамять/производительность5 часов — не совсем чистый запуск, а подготовка данных (импорт) + препроцессинг.