Сообщение Re: Про скорость - почему такая большая проблема? от 12.11.2022 19:21
Изменено 12.11.2022 19:28 vsb
Re: Про скорость - почему такая большая проблема?
Да нет никакой проблемы. Я как-то делал программку на Java. WinAPI через JNI пробрасывал и дергал напрямую. JVM стартует может 0.1 секунды. И всё пошла работать программа. Никакого отличия от C на глаз не было, всё работало абсолютно реактивно. Два раза щелкнул и окошко появилось. Крохотную запускалку на exe делал тоже, по сути получается крохотный exe плюс JVM в виде DLL-ок плюс нагрузка в виде class-файлов.
Уверен, что и с пайтоном можно то же самое сделать.
Просто всем пофиг на скорость.
Если тебе не пофиг — возьми свой любимый стек, тот же пайтон, про который ты написал и попробуй разобраться — от чего там эти тормоза. Выкинь всё лишнее. У меня вот пайтон консольный стартует моментально, без тормозов. WinAPI очевидно тоже работает моментально. Значит что-то происходит между запуском python.exe и вызовами WinAPI, что тормозит выполнение. К примеру в JVM есть два неочевидных фактора, но когда начинает профилировать — они вылазят. Во-первых принято классы паковать в zip-архивы (jar-файлы). Их распаковка занимает время на старте. При этом можно их не паковать или паковать с нулевым сжатием, это даёт прирост в скорости. Думаю, можно и получше формат придумать, до этого я уже не дошёл. Во-вторых JVM проверяет все загружаемые классы на предмет того, не подсовывают ли ей фигню. В целом эта проверка ненужная, я же сам их скомпилировал, откуда там фигня. Поэтому такие проверки раньше можно было отключать, это тоже увеличивало время старта.
Ну и естественно фреймворки надо выкинуть или писать их так, чтобы они не влияли на скорость выполнения.
Уверен, что и с пайтоном можно то же самое сделать.
Просто всем пофиг на скорость.
Если тебе не пофиг — возьми свой любимый стек, тот же пайтон, про который ты написал и попробуй разобраться — от чего там эти тормоза. Выкинь всё лишнее. У меня вот пайтон консольный стартует моментально, без тормозов. WinAPI очевидно тоже работает моментально. Значит что-то происходит между запуском python.exe и вызовами WinAPI, что тормозит выполнение. К примеру в JVM есть два неочевидных фактора, но когда начинает профилировать — они вылазят. Во-первых принято классы паковать в zip-архивы (jar-файлы). Их распаковка занимает время на старте. При этом можно их не паковать или паковать с нулевым сжатием, это даёт прирост в скорости. Думаю, можно и получше формат придумать, до этого я уже не дошёл. Во-вторых JVM проверяет все загружаемые классы на предмет того, не подсовывают ли ей фигню. В целом эта проверка ненужная, я же сам их скомпилировал, откуда там фигня. Поэтому такие проверки раньше можно было отключать, это тоже увеличивало время старта.
Ну и естественно фреймворки надо выкинуть или писать их так, чтобы они не влияли на скорость выполнения.
Re: Про скорость - почему такая большая проблема?
Да нет никакой проблемы. Я как-то делал программку на Java. WinAPI через JNI пробрасывал и дергал напрямую. JVM стартует может 0.1 секунды. И всё пошла работать программа. Никакого отличия от C на глаз не было, всё работало абсолютно реактивно. Два раза щелкнул и окошко появилось. Крохотную запускалку на exe делал тоже, по сути получается крохотный exe плюс JVM в виде DLL-ок плюс нагрузка в виде class-файлов.
Уверен, что и с пайтоном можно то же самое сделать.
Просто всем пофиг на скорость.
Если тебе не пофиг — возьми свой любимый стек, тот же пайтон, про который ты написал и попробуй разобраться — от чего там эти тормоза. Выкинь всё лишнее. У меня вот пайтон консольный стартует моментально, без тормозов. WinAPI очевидно тоже работает моментально. Значит что-то происходит между запуском python.exe и вызовами WinAPI, что тормозит выполнение. К примеру в JVM есть два неочевидных фактора, но когда начинает профилировать — они вылазят. Во-первых принято классы паковать в zip-архивы (jar-файлы). Их распаковка занимает время на старте. При этом можно их не паковать или паковать с нулевым сжатием, это даёт прирост в скорости. Думаю, можно и получше формат придумать, до этого я уже не дошёл. Во-вторых JVM проверяет все загружаемые классы на предмет того, не подсовывают ли ей фигню. В целом эта проверка ненужная, я же сам их скомпилировал, откуда там фигня. Поэтому такие проверки раньше можно было отключать, это тоже увеличивало время старта.
Ну и естественно фреймворки надо выкинуть или писать их так, чтобы они не влияли на скорость выполнения. Нет никакой проблемы на той же жаве писать, как на C, к примеру. CreateWindowExW и пошёл там в цикле GetMessageW/DispatchMessageW или как там было.
Уверен, что и с пайтоном можно то же самое сделать.
Просто всем пофиг на скорость.
Если тебе не пофиг — возьми свой любимый стек, тот же пайтон, про который ты написал и попробуй разобраться — от чего там эти тормоза. Выкинь всё лишнее. У меня вот пайтон консольный стартует моментально, без тормозов. WinAPI очевидно тоже работает моментально. Значит что-то происходит между запуском python.exe и вызовами WinAPI, что тормозит выполнение. К примеру в JVM есть два неочевидных фактора, но когда начинает профилировать — они вылазят. Во-первых принято классы паковать в zip-архивы (jar-файлы). Их распаковка занимает время на старте. При этом можно их не паковать или паковать с нулевым сжатием, это даёт прирост в скорости. Думаю, можно и получше формат придумать, до этого я уже не дошёл. Во-вторых JVM проверяет все загружаемые классы на предмет того, не подсовывают ли ей фигню. В целом эта проверка ненужная, я же сам их скомпилировал, откуда там фигня. Поэтому такие проверки раньше можно было отключать, это тоже увеличивало время старта.
Ну и естественно фреймворки надо выкинуть или писать их так, чтобы они не влияли на скорость выполнения. Нет никакой проблемы на той же жаве писать, как на C, к примеру. CreateWindowExW и пошёл там в цикле GetMessageW/DispatchMessageW или как там было.