История изменений

Сейчас пользователи приложений на электроне улыбнулись. Потому что если электрон и жрет меньше оперативы, то не сильно меньше — это по прежнему жоркая и тормознутая штука.

Проблема не столько в том, сколько памяти жрёт приложение в типовом использовании, а в том, сколько памяти жрёт приложение в пике. К примеру взять дискорд. Я могу сидеть на одном сервере, а могу на ста серверах. Понятно, что в последнем случае памяти надо жрать больше. При этом если я использую JVM, я либо ставлю Mx на последний случай гигов на 5, но тогда первый случай тоже съест эти гиги. Либо я ставлю на первый случай на 500 мегабайтов, но тогда последний случай тупо упадет по OOM, хотя у человека памяти на машине хватает. Ну либо просить пользователя редактировать стартовые скрипты, что, очевидно, подойдёт разве что для программистских инструментов (как это делает Idea).

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

Скорей всего это не проблема. Все эти мелкие объекты лежат в молодом поколении и собираются очень быстро. В JVM не куча, а несколько куч. Я не спорю, что это не слишком хорошо, но на практике это работает достаточно быстро и обычно не является главным источником тормозов, если код написан более-менее аккуратно.

Тот же javac написан на Java и компилирует эту самую Java очень быстро (в отличие от всяких Gradle-ов, которые его вызывают, но при этом непонятно почему тормозят как чёрт знает что, хотя вроде ничего толком и не делают).

Не, я не спорю, если взять кусок кода, аккуратно написать его на C++/Rust и скомпилировать под Wasm, вероятно он может опередить аналогичный Java-код. Но тут есть мнение, что всё же Java это язык более высокого уровня. А если к такому сравнению подходить, то с тем же успехом можно этот же код написать на C++/Rust и скомпилировать под конечную архитектуру и потом вызывать его из Java аналогично тому, как это делает JavaScript. Это более честное сравнение. А вот когда в WASM добавят GC и какой-нибудь похожий на Java язык реализуют (а может и саму Java, чем чёрт не шутит), тогда и можно будет сравнивать.

Сейчас пользователи приложений на электроне улыбнулись. Потому что если электрон и жрет меньше оперативы, то не сильно меньше — это по прежнему жоркая и тормознутая штука.

Проблема не столько в том, сколько памяти жрёт приложение в типовом использовании, а в том, сколько памяти жрёт приложение в пике. К примеру взять дискорд. Я могу сидеть на одном сервере, а могу на ста серверах. Понятно, что в последнем случае памяти надо жрать больше. При этом если я использую JVM, я либо ставлю Mx на последний случай гигов на 5, но тогда первый случай тоже съест эти гиги. Либо я ставлю на первый случай на 500 мегабайтов, но тогда последний случай тупо упадет по OOM, хотя у человека памяти на машине хватает. Ну либо просить пользователя редактировать стартовые скрипты, что, очевидно, подойдёт разве что для программистских инструментов (как это делает Idea).

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

Скорей всего это не проблема. Все эти мелкие объекты лежат в молодом поколении и собираются очень быстро. В JVM не куча, а несколько куч. Я не спорю, что это не слишком хорошо, но на практике это работает достаточно быстро и обычно не является главным источником тормозов, если код написан более-менее аккуратно.

Тот же javac написан на Java и компилирует эту самую Java очень быстро (в отличие от всяких Gradle-ов, которые его вызывают, но при этом непонятно почему тормозят как чёрт знает что, хотя вроде ничего толком и не делают).

Не, я не спорю, если взять кусок кода, аккуратно написать его на C++/Rust и скомпилировать под Wasm, вероятно он может опередить аналогичный Java-код. Но тут есть мнение, что всё же Java это язык более высокого уровня. А если к такому сравнению подходить, то с тем же успехом можно этот же код написать на C++/Rust и скомпилировать под конечную архитектуру и потом вызывать его из Java аналогично тому, как это делает JavaScript. Это более честное сравнение.

Сейчас пользователи приложений на электроне улыбнулись. Потому что если электрон и жрет меньше оперативы, то не сильно меньше — это по прежнему жоркая и тормознутая штука.

Проблема не столько в том, сколько памяти жрёт приложение в типовом использовании, а в том, сколько памяти жрёт приложение в пике. К примеру взять дискорд. Я могу сидеть на одном сервере, а могу на ста серверах. Понятно, что в последнем случае памяти надо жрать больше. При этом если я использую JVM, я либо ставлю Mx на последний случай гигов на 5, но тогда первый случай тоже съест эти гиги. Либо я ставлю на первый случай на 500 мегабайтов, но тогда последний случай тупо упадет по OOM, хотя у человека памяти на машине хватает. Ну либо просить пользователя редактировать стартовые скрипты, что, очевидно, подойдёт разве что для программистских инструментов (как это делает Idea).

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

Скорей всего это не проблема. Все эти мелкие объекты лежат в молодом поколении и собираются очень быстро. В JVM не куча, а несколько куч. Я не спорю, что это не слишком хорошо, но на практике это работает достаточно быстро и обычно не является главным источником тормозов, если код написан более-менее аккуратно.

Тот же javac написан на Java и компилирует эту самую Java очень быстро (в отличие от всяких Gradle-ов, которые его вызывают, но при этом непонятно почему тормозят как чёрт знает что, хотя вроде ничего толком и не делают).

Сейчас пользователи приложений на электроне улыбнулись. Потому что если электрон и жрет меньше оперативы, то не сильно меньше — это по прежнему жоркая и тормознутая штука.

Проблема не столько в том, сколько памяти жрёт приложение в типовом использовании, а в том, сколько памяти жрёт приложение в пике. К примеру взять дискорд. Я могу сидеть на одном сервере, а могу на ста серверах. Понятно, что в последнем случае памяти надо жрать больше. При этом если я использую JVM, я либо ставлю Mx на последний случай гигов на 5, но тогда первый случай тоже съест эти гиги. Либо я ставлю на первый случай на 500 мегабайтов, но тогда последний случай тупо упадет по OOM, хотя у человека памяти на машине хватает. Ну либо просить пользователя редактировать стартовые скрипты, что, очевидно, подойдёт разве что для программистских инструментов (как это делает Idea).

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

Скорей всего это не проблема. Все эти мелкие объекты лежат в молодом поколении и собираются очень быстро. В JVM не куча, а несколько куч. Я не спорю, что это не слишком хорошо, но на практике это работает достаточно быстро и не является главным источником тормозов, если код написан более-менее аккуратно.

Тот же javac написан на Java и компилирует эту самую Java очень быстро (в отличие от всяких Gradle-ов, которые его вызывают, но при этом непонятно почему тормозят как чёрт знает что, хотя вроде ничего толком и не делают).

Сейчас пользователи приложений на электроне улыбнулись. Потому что если электрон и жрет меньше оперативы, то не сильно меньше — это по прежнему жоркая и тормознутая штука.

Проблема не столько в том, сколько памяти жрёт приложение в типовом использовании, а в том, сколько памяти жрёт приложение в пике. К примеру взять дискорд. Я могу сидеть на одном сервере, а могу на ста серверах. Понятно, что в последнем случае памяти надо жрать больше. При этом если я использую JVM, я либо ставлю Mx на последний случай гигов на 5, но тогда первый случай тоже съест эти гиги. Либо я ставлю на первый случай на 500 мегабайтов, но тогда последний случай тупо упадет по OOM, хотя у человека памяти на машине хватает. Ну либо просить пользователя редактировать стартовые скрипты, что, очевидно, подойдёт разве что для программистских инструментов (как это делает Idea).

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

Скорей всего это не проблема. Все эти мелкие объекты лежат в молодом поколении и собираются очень быстро. В JVM не куча, а несколько куч. Я не спорю, что это не слишком хорошо, но на практике это работает достаточно быстро и не является главным источником тормозов, если код написан более-менее аккуратно.