В мире БД есть такая штука - DeWitt clause, согласно которой не со всякими БД можно проводить сравнения производительности и потом их публиковать. Возможно в мире GUI фреймворков тоже есть что-то похожее.
Программным путём. Одно дело, когда где-то что-то читал и поверил на слово, а другое дело, когда сам попробовал, в руках покрутил и убедился - да, и правда всё так. Такие знания, мне кажется, полезнее, чем теоретические, просто прочитанные.
Наверное еще стоит сказать, что делать, когда усы вылезают за пределы фактических данных. Насколько я помню и matplotlib и seaborn усы обрезают в данном случае.
x = np.linspace(0, 10, 1000)
x = np.linspace(0, 2 * np.pi, 100)
Согласитесь, это немного разные количества.
методика проста - вывод sin()+шум в виде графика с максимальным fps и измерение этого fps
объем точек соответствует задаче вывода графика звукового сигнала в реальном времени. При 60 гц fps 44100 частоте дискртеизации это 735 точек при меньшей частоте дискретизации будет меньшее кол-во точек, так что с кол-вом точек все Ок.
Ну так напишите в самом начале о своей методике. В моей практике ограничивающим фактором для выбора библиотек для построения графиков были сотни тысяч точек. И там уже важными становятся другие возможности.
Что может лимитировть действительно никому не понятно, например 12 fps в matplotlib самой совершенной и мошной ситеме, ведь ее писали одни из лучших программистов в мире и вот 12 fps Ну как так? Может вы нам объясните?
Наверное, все таки стоит поправить свое изначальное предложение. Было:
При разработке 2D графики на Python лимитировать может производительность, особенно если вы стремитесь к высокому количеству кадров в секунду (FPS).
Стало (например)
При разработке приложений с отображением 2D графиков на Python лимитировать может производительность библиотек, используемых для отображения, особенно если вы стремитесь к высокому количеству кадров в секунду (FPS).
Вроде как можно
import numpy as np
from mayavi import mlab
import time
# Создаем фигуру и оси
fig = mlab.figure(size=(800, 600), bgcolor=(1, 1, 1))
Статья какая-то бессмысленная и беспощадная. Нет единой методологии тестирования, в скриптах используются различные входные данные, тестируются на каких-то детских объемах точек.
При разработке 2D графики на Python лимитировать может производительность, особенно если вы стремитесь к высокому количеству кадров в секунду (FPS).
Не понятно, кто кого может лимитировать.
В этой статье рассмотрим несколько наиболее популярных графических библиотек, их производительность и возможности достижения высоких значений FPS.
Если уж и писать про возможности - то писать о подходах, которые на данных библиотеках позволяют достигать высоких значений. От громадных простыней кода пользы чуть меньше, чем никакой.
Я, простите меня, не понимаю как вы перешли от конкурентных алгоритмов к формашлепству. Я ответил в первоначальном сообщении на процитированный там же ответ автора поста. А отвечать вам на ваши вопросы, которые никаким образом не относятся к моему первоначальному ответу, больше уже сказанного, не планирую.
@Eclips4поздравляю!
А еще в некоторых версиях Python комбинацией
unraisablehookиaddaudithookможно свалить интерпретатор с SegFault :)Спасибо!
Ссылка на изменения лексера не работает.
Спасибо! Есть еще куда расти :)
Спасибо, взаимно! Кстати, мой первый реквест вы замержили :)
По поводу учебы и карьеры - пожелаю удачи, у вас хороший старт и впереди большие возможности.
А сколько сейчас удается уделять времени? Не мешает ли работа? :)
Все адекватные люди перестают быть такими как только заходит разговор за деньги.
В мире БД есть такая штука - DeWitt clause, согласно которой не со всякими БД можно проводить сравнения производительности и потом их публиковать. Возможно в мире GUI фреймворков тоже есть что-то похожее.
Согласен
Вы же в курсе про
wtfpython? Кратко про преаллокацию [-5, 256] было тут wtfpython: How not to use is operatorНаверное еще стоит сказать, что делать, когда усы вылезают за пределы фактических данных. Насколько я помню и matplotlib и seaborn усы обрезают в данном случае.
Оптимизатор глазка это очень хорошо!
Скрытый текст
В самой статье должно быть также.
Согласитесь, это немного разные количества.
Ну так напишите в самом начале о своей методике. В моей практике ограничивающим фактором для выбора библиотек для построения графиков были сотни тысяч точек. И там уже важными становятся другие возможности.
Наверное, все таки стоит поправить свое изначальное предложение. Было:
Стало (например)
Вроде как можно
Статья какая-то бессмысленная и беспощадная. Нет единой методологии тестирования, в скриптах используются различные входные данные, тестируются на каких-то детских объемах точек.
Не понятно, кто кого может лимитировать.
Если уж и писать про возможности - то писать о подходах, которые на данных библиотеках позволяют достигать высоких значений. От громадных простыней кода пользы чуть меньше, чем никакой.
Ну и, конечно, ссылка на телеграм канал.
Я, простите меня, не понимаю как вы перешли от конкурентных алгоритмов к формашлепству. Я ответил в первоначальном сообщении на процитированный там же ответ автора поста. А отвечать вам на ваши вопросы, которые никаким образом не относятся к моему первоначальному ответу, больше уже сказанного, не планирую.
Вряд ли во мне вы найдете руководителя по этому вопросу, простите.
Yandex выпустил свой Perforator: новая система непрерывного профилирования теперь в опенсорсе и он вроде как умеет интегрироваться с opentelemetry - это к слову о трейсинге.
Этим могут заняться программисты, у которых плохо с пониманием прочитанного.