Значит нужно выбирать jre с х86

Да, возможно выбор не оптимальный и будет требовать трансляции, но пусть тогда юзер выбирает сам какой пакет electron ставить и какой в итоге оно на его базе уже запустит

Это приведет к деградации производительности запускаемого приложения. Надо ставить jre под arm

Ну это же проблема пользователя выбрать оптимально, если действительно нужно и можно пожертвовать при этом самой arch электрона, наверное просто стоит сделать ручной выбор

Пользователь даун в базе своей. И это не должно служить причиной неудовлетворительного экспириенса от моего софта. Хороший софт устойчив к идиотам. И это именно тот случай. Вероятен кейс когда чел выберет билд под x86 а не под x64 потому что "ну 86 больше чем 64 - значит работать быстрее будет"

на основании чего такие выводы?

Если что-то может пойти не так то оно обязательно пойдет не так

Пользователь даун в базе своей. И это не должно служить причиной неудовлетворительного экспириенса от моего софта. Хороший софт устойчив к идиотам. И это именно тот случай. Вероятен кейс когда чел выберет билд под x86 а не под x64 потому что "ну 86 больше чем 64 - значит работать быстрее будет"

Пользователь даун в базе своей. И это не должно служить причиной неудовлетворительного экспириенса от моего софта. Хороший софт устойчив к идиотам. И это именно тот случай. Вероятен кейс когда чел выберет билд под x86 а не под x64 потому что "ну 86 больше чем 64 - значит работать быстрее будет"

Пользователь даун в базе своей. И это не должно служить причиной неудовлетворительного экспириенса от моего софта. Хороший софт устойчив к идиотам. И это именно тот случай. Вероятен кейс когда чел выберет билд под x86 а не под x64 потому что "ну 86 больше чем 64 - значит работать быстрее будет"

20% усилий это 80% результата, остальное может быть и не нужно

Пользователь даун в базе своей. И это не должно служить причиной неудовлетворительного экспириенса от моего софта. Хороший софт устойчив к идиотам. И это именно тот случай. Вероятен кейс когда чел выберет билд под x86 а не под x64 потому что "ну 86 больше чем 64 - значит работать быстрее будет"

К слову, нет варианта использовать инсталлер, который сам подберёт оптимальный билд приложения, а уже в приложении полагаться на ответ ноды и ставить нужный JRE?

Он не может определить arch тк ось даёт в лучшем случае "предпологаемый" или тот что эмулируется ну или тот под который собран сам бинарь вне зависимости идёт запуск с трансляцией инструкций или нет

Честно не могу вот сказать точно, но не думаю что от запуска х32 системе х64 прога будет работать медленнее Но и быстрее сомневаюсь. Оперировать 32 бит регистрами на системе с возможностью в 64 точно не проблема

x64 насколько помню, только раскладываемость на процессы/ядра более толково. В остальном те же плюшки. Быстрее? зависит от сложности программы. Будет простая - не заметишь разницы, будет ворд - заметишь и сильно

Думаю просто то что в 64 бит занимает 1 такт, будет занимать 2

не 2, а от ядер процессора, вроде. И то по нагрузке на ЦП

К слову, нет варианта использовать инсталлер, который сам подберёт оптимальный билд приложения, а уже в приложении полагаться на ответ ноды и ставить нужный JRE?

Человеку предстоит поднимать рантайм жабы, предполагаю, что для майнкрафта. Люди не заслуживают страданий из-за отсутствия нормального определения архитектуры.

на основании чего такие выводы?

Пытаюсь разобраться со сборкой приложения через packager, есть несколько вопросов: я правильно понимаю, что packager упаковывает node.js прямо в бинарник? Версия node.js используется та же, которая установлена в системе?

Nodejs уже вшит в прекомпиленный бинарник electron'а. Electron Packager лишь берет нужный прекомпиленный бинарь, собирает asar архив с логикой приложения, патчит бинарь Fuse'ами и метадатой (пр. светит иконку) Версия nodejs в бинарнике electron'а не зависит от версии nodejs, установленной на компе

Ага, понятно. Получается, при разработке желательно использовать ту же версию ноды, что и в электроне, чтобы потом сюрпризов не было?

Я вижу в этом смысл лишь при unit тестировании фич, которые позже попадут в прилку. Т.е. при тестах, которые прогоняются вне электроновского бинарника. Если юнит тесты - это не про твой проект, то в подобной предосторожности я не вижу необходимости, т.к. даже в режиме разработки используется nodejs из бинарника электрона

Спасибо, и еще вопрос: packager создает папку с кучей файлов - вся эта папка и есть полноценное приложение? Т.е. из нее я потом могу создать rpm-пакет, например?

Electron Packager не занимается упаковкой приложения в инсталер, зипку, rpm-пакет etc. Он лишь собирает прилку as is. Т.е. вопросы дистрибуции лежат вне компетенции packager'а Тут на сцену приходит Electron Forge, который умеет дружить Packager с Maker'ами. Вот последние и создают файл, который ты отдашь юзеру

Я понимаю, вопрос в том, что именно упаковывать в rpm. Forge я не могу использовать, потому что мне нужно собрать пакет для Альт Линукса, а там своя система сборки.

Всем привет! Я новенький, и у меня только начались первые потуги и борьба с электроном, но больше всего меня волнует как электрон запускается, в общем при первом запуске после включения ПК использую команду npm start и мое приложение ест мало оперативы, в районе 30-40 mb но как только я его перезапускаю, несколько раз, сразу начинает есть раза в 3-4 больше и процессов электрона запущено уже 3 а не один как было при первом запуске приложения, это нормальные моменты или нужно что-то учитывать, очищать кэш, может какой нибудь особый рестарт проекта делать, или может я совсем отсталый и будут более мудрые советы, а может эта проблема совсем и не проблема а норма? PS я дизайнер и делаю небольшое приложение для себя, использую ai агента поэтому не кидайтесь сильно яйцами, мы дизайнеры тоже ai не сильно жалуем))) приложение работает с canvas плюс библиотека fabric.js подумал вдруг важный нюанс!

Electron всегда запускает несколько процессов: main, utility, gpu-process и renderer (если окно открыто). Это нормально.

А значит это норма, просто у меня своеобразная фобия из за проблем с кэшем, думал здесь меня тоже это настигло) получается для электрона это нормально если он занимает 200 - 300 mb оперативы? спасибо за ответ!👍

Нет, это не нормально. Хелоу ворлд занимает ~120 метров. Покажи дерево процессов приложения в диспетчере задач с велюченным столбцом "командная строка"

Вообще при первом запуске всего один электрон запущен а при повторных их становится 3 ну и плюс мое приложение image canvas, сейчас занимает где то 80 mb оперативы, 200-300 занимает это когда на канвас много картинок добавлю, но это логично они же должны где то разместится в памяти, так что думаю это норма!

Вообще как раз 4 процесса, которые ты кинул, это база

Нет, это не нормально. Хелоу ворлд занимает ~120 метров. Покажи дерево процессов приложения в диспетчере задач с велюченным столбцом "командная строка"

Всем привет! Я новенький, и у меня только начались первые потуги и борьба с электроном, но больше всего меня волнует как электрон запускается, в общем при первом запуске после включения ПК использую команду npm start и мое приложение ест мало оперативы, в районе 30-40 mb но как только я его перезапускаю, несколько раз, сразу начинает есть раза в 3-4 больше и процессов электрона запущено уже 3 а не один как было при первом запуске приложения, это нормальные моменты или нужно что-то учитывать, очищать кэш, может какой нибудь особый рестарт проекта делать, или может я совсем отсталый и будут более мудрые советы, а может эта проблема совсем и не проблема а норма? PS я дизайнер и делаю небольшое приложение для себя, использую ai агента поэтому не кидайтесь сильно яйцами, мы дизайнеры тоже ai не сильно жалуем))) приложение работает с canvas плюс библиотека fabric.js подумал вдруг важный нюанс!

Возможно у тебя что-то удерживает процессы

В целом при разработке и работе с сборщиком при определённых ошибках и перезапускр после изменения кода они могут подвисать, но в нормальном виде точно нет. И single instance lock нужен, если прилодение должно запустится только в одном экземпляре в любом случае

А ок, то есть подобные запуски типа npm start могут давать некоторые тормоза после изменения кода я правильно понял? Я это примерно так и наблюдал, чем больше я вносил изменений и изменял тем дольше само приложение запускалось и тормозило, а после перезагрузки работало хорошо, надо наверное сделать тестовый билд и протестить его. Спасибо за ответ!

Почему не не прихлопывает старые прилы, или они возможно игнорируют где то в обработчиках exit

Хм мне нужно это изучить, я посмотрел, чтобы это могло значить и понял что сам fabric.js может плохо переносить hot reload, хотя скорее всего у меня это вообще не реализовано или сделано но как ты и писал через Ж, изучу попробую реализовать, пока что слабо понимаю о чем речь, спасибо за советы, теперь есть о чем подумать!

Столкнулся с такой проблемой: если при передаче строки из второго экземпляра приложения в первый через requestSingleInstanceLock() в строке есть /Р (косая черта и большая русская Р), то в первом экземпляре строку прочитать невозможно, там null. Это что за магическое сочетание или просто какой-то баг?

Запили плз проект с воспроизводимой проблемой. Интересно посмотреть как ты данные шаришь между инстансами

Как как, согласно документации

А как в объекте может быть строка

Запили плз проект с воспроизводимой проблемой. Интересно посмотреть как ты данные шаришь между инстансами