Верно, но а) эта оптимизация не применима в общем случае, в отличии от остальных описанных
б) я не просто так указывал процентное изменение, 1.5сек вполне достаточно, но код, работающий с 600*600 за 1.5 сек отработает на, скажем 6000*6000 (адекватное разрешение для изучения фрактала) за ~150сек, а тут уж даже десятые доли процента не помешают.
После всех оптимизаций+хак, 6000*6000 обрабатывается за 79сек, что всяко лучше 150.)
Предчувствую геморрой при разработке универсальных прог, под оба интерфейса…
Хотя, с другой стороны, под одну ОСь писать придется, а не под зоопарк Win/iOS/WP/Android/webOS/и проч и проч
Да и на самом деле ситуация немного сложнее чем Вы описали — задачи с симметричными решениями — частая ситуация, поэтому найдя ось симметрии можно действительно сократить время выполнения вдвое.
Но все же, это далеко от общего случая поэтому и указанно вскользь, как небольшой хак.
Как ни странно, замена pc = 0.5 — 0.5 * x / p, приводит к увеличению времени работы на 0.17сек, т.е. на 5%. Вечером попробую разобраться, интересный момент.
Замена y ** 2 на y * y дает прирост в ~4%, т.к. даже средний цикл выполняется ширина * высота раз, т.е. в данном случае 600 * 600 = 360000 раз.
Добавлю еще:
Для если бы значения width изменялись в течении работы программы, то, да, их безусловно требовалось бы поместить на уровень выше частовызываемой функции вместо того чтобы считать в ней.
Днем помещу Ваши замечания в пост, спасибо за коментакрий!
С первым — в общем случае вы правы, но к функциям полученным на шаге 0 это не совсем применимо, чаще всего они отрабатывают один раз. Но для часто вызываемых функций Ваше решение безусловно будет верней.
Со вторым — не совсем. Интерпретатор при запуске создает кортеж co_constants, в котором лежат значения неизменные для всего вызова функции, так что по сути эти значения будут вычислены единожды при запуске.
хм, уменьшив яркость не увидел ничего, но уменьшив яркость в -100 — -150 в ШФ становится видно, да. в принципе, белый, да и любой монотонный фон действительно не самое удачный объект.
вот (2.4Мб) немонотонный объект, на нем сколько не извращался — следов «вмешательства не заметил».
файл «забит» полностью.
Моя задача — заменить два младших бита в байте на нужные. Возможно неправ, но не вижу способа выполнить ее одними логическими операторами, хотя возможно он есть. Попробую вечером.
б) я не просто так указывал процентное изменение, 1.5сек вполне достаточно, но код, работающий с 600*600 за 1.5 сек отработает на, скажем 6000*6000 (адекватное разрешение для изучения фрактала) за ~150сек, а тут уж даже десятые доли процента не помешают.
После всех оптимизаций+хак, 6000*6000 обрабатывается за 79сек, что всяко лучше 150.)
Хотя, с другой стороны, под одну ОСь писать придется, а не под зоопарк Win/iOS/WP/Android/webOS/и проч и проч
Да и на самом деле ситуация немного сложнее чем Вы описали — задачи с симметричными решениями — частая ситуация, поэтому найдя ось симметрии можно действительно сократить время выполнения вдвое.
Но все же, это далеко от общего случая поэтому и указанно вскользь, как небольшой хак.
pc = 0.5 — 0.5 * x / p, приводит к увеличению времени работы на 0.17сек, т.е. на 5%. Вечером попробую разобраться, интересный момент.Замена
y ** 2наy * yдает прирост в ~4%, т.к. даже средний цикл выполняетсяширина * высотараз, т.е. в данном случае600 * 600 = 360000раз.Добавлю еще:
Для если бы значения width изменялись в течении работы программы, то, да, их безусловно требовалось бы поместить на уровень выше частовызываемой функции вместо того чтобы считать в ней.
Днем помещу Ваши замечания в пост, спасибо за коментакрий!
Со вторым — не совсем. Интерпретатор при запуске создает кортеж co_constants, в котором лежат значения неизменные для всего вызова функции, так что по сути эти значения будут вычислены единожды при запуске.
А по теме — слова после аккустики, включая ее, искаверканы чрезмерно, читать просто тяжело:
— рвет мозг
вот (2.4Мб) немонотонный объект, на нем сколько не извращался — следов «вмешательства не заметил».
файл «забит» полностью.
отвечу не раньше вечера субботы, заранее извиняюсь.
Функцию vec() рассматривал при разработке, но так и не смог применить в данной задаче
В следующей сборке попробую тругой принцип работы с пользователем
Думал использовать push но решил что скорость будет порядка 'Arr copy.
Ну, будет уроком на будущее.)