Попробуйте что-то на основе flamegraph, он вроде как должен существенно снижать размер профиля (но у меня все равно получались профили по несколько Гб с примерно таким же результатом как у вас). У того же остина довольно простой формат, котороый можно фильтровать перед анализом "глазками".
Если вы говорите про трейсинг, то возможно вам будет интересно посмотреть на pyroscope, сам его я не использовал (у нас немного другое направление), но выглядит он интересно.
Также большинство указанных в статье инструментов (в разделе Другие инструменты) умеют подцепляться к запущенным приложениям и строить либо FlameGraph, либо выгружать данные в формате Google Trace Event.
А по поводу ванильных примеров - я применял austin на реальном большом десктопном приложении, применял с пользой. С неванильными примерами есть другая проблема - ниже об этом писали - это получающиеся большие логи, которые надо как то предобрабатывать.
Выше уже ответили — различные оптимизации. Мне часто приходится решать задачи улучшения производительности в довольно большой кодовой базе, и там с ходу не понятно куда надо нанести «удар кувалдой».
Все так с .csv - у них хороший парсер для csv - отсюда и результат. Т.е. дело не только в том что они используют mmap, но и в том что остальной код лучше.
Вот у вас есть реальный опыт pandas/polars, судя по вашим комментариям он гораздо интереснее статьи.
Алексей, расскажите, пожалуйста, что вы имеете в виду, когда пишите "Архитектура базируется на NumPy — это ограничивает обработку больших массивов данных, помещающихся в память одного потока."
Rust позволяет эффективно управлять памятью и гарантирует отсутствие состояния гонки. - это просто общие слова, которые не имеют отношения к делу.
Если вы противопостовляете pandas + Dask и polars, надо говорить не про "Polars же написан на Rust — языке программирования, который славится своей безопасностью и высокой производительностью." - а про наличие streaming API из коробки (которое появилось не само по себе).
А вот чтобы было более честное сравнение - "Данные хранятся в колонках, так что чтение и обработка становятся более эффективными." - вы не пробовали те же тесты запустить в pandas если выбрано PyArrow в качестве сравнения? Сюда же и про mmap - оно ведь тоже не на равном месте появляется. Попробуйте так же работать с CSV или XLSX форматами :)
Что касается API, то у Polars свой собственный DataFrame API (иммутабельный, в отличие от Pandas), а еще есть поддержка SQL. У DuckDB — только SQL. А DuckDB то каким образом к pandas относится?
А в абзаце про слияние и join у вас написано про фильтрацию.
Я ознакомился с Boost.PFR и вы правы, в том, что большая часть использований может быть им покрыта. Если мы говорим про POD/POCO типы.
Но, тот же linq2db активно пользуется атрибутивной разметкой и прочей метаинформацией, которая свзяна с полями и свойствами. Насколько я понимаю, такого сделать с помощью Boost.PFR нельзя и опять же, имхо, без поддержки со стороны языка невозможно. Можно придумать обходные варианты с fluent mapping или builders (и в новых версиях linq2db оно тоже доступно).
Также я посмотрел что Boost.PFR использует loophole, что принципиально снимает ограничение на использование типов из других сборок/DLL.
Но даже у вас в userver запросы пишутся вручную (я ознакомился бегло, рад буду ошибиться). Что является источником ошибок (привет sql injection), хотя, насколько я понял, вы стараетесь от этого защищаться.
LINQ и различные библиотеки (linq2db, EntityFramework) и другие снимают с меня как с программиста необходимость писать SQL запросы руками (при этом linq2db генерирует очень качественные запросы), готовя за меня prepared statements и передавая туда параметры (с проверкой типов на уровне С#). т. е. я принципиально не могу написать неправильный запрос и забыть передать в него параметры или передать не те.
Я за все время могу наверное вспомнить единицы запросов, котороые я бы написал.
При этом тот же linq2db позволяет расширять список функций, которые он может использовать при создании запросов или при обратном отображении — функции могут быть помечены специальными атрибутами и «выполняться» либо на серверной либо на клиентской стороне.
Судя по тому, что вы делаете в Boost.PFR и в целом куда движется язык аналогичную функциональность (с ограничениями) можно сделать и на С++, но выглядит это все очень дорого и нужны эксперты‑энтузиасты, вроде вас для этого. Тот же С# дает более простые инструменты.
Разговор же был не про то что можно сделать через std::function или обычный делегат в c#, а про то что для этого можно сгенерировать специализированный код в рантайме, который будет эффективнее списка предикатов.
На второй вопрос выше я попробую ответить позже - несколько последних лет я не пользуюсь c#.
Я наверное не понимаю вашего вопроса. Но все равно попробую ответить :)
Зачем создавать в рантайме - потому что в компайл-тайме всего выражения еще нет, например. В с++ есть аналог - это expression tree, но он ограничен статическими выражениями, но при этом позволяет создавать код, который нам нужен и как нам нужно . В c# позволяет сделать тоже самое, но не ограничивает вас только статическими выражениями.
А классы в рантайме для этого надо создавать, чтобы в сгенерированном коде не было дополнительных накладных расходов и он был создан только под конкретную задачу. Хороший пример производительного orm, который использует эту технологию - linq2db. Я бы посоветовал ознакомиться, но вы вряд ли будете этим заниматься :)
Более продвинутая структура t‑digest явно применяет k‑means кластеризацию для получения лучшего отношения размера к погрешности. Её реализация уже успешно применялась в Яндексе.
Применялась вообще в Яндексе или в YTsaurus? Планируется применяться вместо Q-digest? У вас своя реализация или от Facebook?
Я настраивал как здесь описано - Obsidian+Github вместо Notion: синхронизация, бекап и версионность (3-в-1) / Хабр, но в итоге на ios заменил fit на git (писал у себя в постах если интересно). Дополнительные приложения открывать не надо - obsidian и плагин git все делают сами.
Попробуйте что-то на основе flamegraph, он вроде как должен существенно снижать размер профиля (но у меня все равно получались профили по несколько Гб с примерно таким же результатом как у вас). У того же остина довольно простой формат, котороый можно фильтровать перед анализом "глазками".
Если вы говорите про трейсинг, то возможно вам будет интересно посмотреть на pyroscope, сам его я не использовал (у нас немного другое направление), но выглядит он интересно.
Также большинство указанных в статье инструментов (в разделе Другие инструменты) умеют подцепляться к запущенным приложениям и строить либо FlameGraph, либо выгружать данные в формате Google Trace Event.
А по поводу ванильных примеров - я применял austin на реальном большом десктопном приложении, применял с пользой. С неванильными примерами есть другая проблема - ниже об этом писали - это получающиеся большие логи, которые надо как то предобрабатывать.
Для питона есть, в статье есть несколько ссылок, которые точно умеют - это austin, py-spy, pyinstrument.
Выше уже ответили — различные оптимизации. Мне часто приходится решать задачи улучшения производительности в довольно большой кодовой базе, и там с ходу не понятно куда надо нанести «удар кувалдой».
Все так с .csv - у них хороший парсер для csv - отсюда и результат. Т.е. дело не только в том что они используют mmap, но и в том что остальной код лучше.
Вот у вас есть реальный опыт pandas/polars, судя по вашим комментариям он гораздо интереснее статьи.
Алексей, расскажите, пожалуйста, что вы имеете в виду, когда пишите "Архитектура базируется на NumPy — это ограничивает обработку больших массивов данных, помещающихся в память одного потока."
Rust позволяет эффективно управлять памятью и гарантирует отсутствие состояния гонки. - это просто общие слова, которые не имеют отношения к делу.
Если вы противопостовляете pandas + Dask и polars, надо говорить не про "Polars же написан на Rust — языке программирования, который славится своей безопасностью и высокой производительностью." - а про наличие streaming API из коробки (которое появилось не само по себе).
А вот чтобы было более честное сравнение - "Данные хранятся в колонках, так что чтение и обработка становятся более эффективными." - вы не пробовали те же тесты запустить в pandas если выбрано PyArrow в качестве сравнения? Сюда же и про mmap - оно ведь тоже не на равном месте появляется. Попробуйте так же работать с CSV или XLSX форматами :)
Что касается API, то у Polars свой собственный DataFrame API (иммутабельный, в отличие от Pandas), а еще есть поддержка SQL. У DuckDB — только SQL. А DuckDB то каким образом к pandas относится?
А в абзаце про слияние и join у вас написано про фильтрацию.
В целом вы могли бы и лучше, но явно халтурите.
В этом году был доклад на эту тему - B-tree Optimisation for Numerical In-memory Indexes | Talk at С++ Russia 2024 (слайды cpp-russia-03-06.pdf)
Для тех кто хочет копнуть глубже - цикл статей от разработчика оптимизирующих компиляторов - Поговорим об оптимизирующих компиляторах. Сказ первый: SSA-форма / Хабр
Речь пойдет об одном из наших open source инструментов ― трекере ошибок Хоук.
Хорошо бы дать тогда ссылку на репозиторий, а не на сам трекер, тем более с отслеживанием переходов.
А только я один обращаю внимание на дату первого апреля или это известная всем не шутка?
Я ознакомился с Boost.PFR и вы правы, в том, что большая часть использований может быть им покрыта. Если мы говорим про POD/POCO типы.
Но, тот же linq2db активно пользуется атрибутивной разметкой и прочей метаинформацией, которая свзяна с полями и свойствами. Насколько я понимаю, такого сделать с помощью Boost.PFR нельзя и опять же, имхо, без поддержки со стороны языка невозможно. Можно придумать обходные варианты с fluent mapping или builders (и в новых версиях linq2db оно тоже доступно).
Также я посмотрел что Boost.PFR использует loophole, что принципиально снимает ограничение на использование типов из других сборок/DLL.
Но даже у вас в userver запросы пишутся вручную (я ознакомился бегло, рад буду ошибиться). Что является источником ошибок (привет sql injection), хотя, насколько я понял, вы стараетесь от этого защищаться.
LINQ и различные библиотеки (linq2db, EntityFramework) и другие снимают с меня как с программиста необходимость писать SQL запросы руками (при этом linq2db генерирует очень качественные запросы), готовя за меня prepared statements и передавая туда параметры (с проверкой типов на уровне С#). т. е. я принципиально не могу написать неправильный запрос и забыть передать в него параметры или передать не те.
Я за все время могу наверное вспомнить единицы запросов, котороые я бы написал.
При этом тот же linq2db позволяет расширять список функций, которые он может использовать при создании запросов или при обратном отображении — функции могут быть помечены специальными атрибутами и «выполняться» либо на серверной либо на клиентской стороне.
Судя по тому, что вы делаете в Boost.PFR и в целом куда движется язык аналогичную функциональность (с ограничениями) можно сделать и на С++, но выглядит это все очень дорого и нужны эксперты‑энтузиасты, вроде вас для этого. Тот же С# дает более простые инструменты.
Разговор же был не про то что можно сделать через std::function или обычный делегат в c#, а про то что для этого можно сгенерировать специализированный код в рантайме, который будет эффективнее списка предикатов.
На второй вопрос выше я попробую ответить позже - несколько последних лет я не пользуюсь c#.
Вместо того, чтобы неумно зубоскалить ознакомьтесь с linq2db, например.
Например, набор фильтров, которые пользователь создает через UI или предикаты бизнес-логики, которые мы загружаем из отдельной сборки.
Я наверное не понимаю вашего вопроса. Но все равно попробую ответить :)
Зачем создавать в рантайме - потому что в компайл-тайме всего выражения еще нет, например. В с++ есть аналог - это expression tree, но он ограничен статическими выражениями, но при этом позволяет создавать код, который нам нужен и как нам нужно . В c# позволяет сделать тоже самое, но не ограничивает вас только статическими выражениями.
А классы в рантайме для этого надо создавать, чтобы в сгенерированном коде не было дополнительных накладных расходов и он был создан только под конкретную задачу. Хороший пример производительного orm, который использует эту технологию - linq2db. Я бы посоветовал ознакомиться, но вы вряд ли будете этим заниматься :)
Прям не тяжело тяжело, но позволяет создавать эффективный код для linq запросов, оптимизированный под конкретное выражение - https://learn.microsoft.com/ru-ru/dotnet/csharp/linq/how-to-build-dynamic-queries
Есть хорошая ретроспектива - Дизайн и эволюция constexpr в C++ / Хабр
Спасибо за ответ!
Применялась вообще в Яндексе или в YTsaurus? Планируется применяться вместо Q-digest? У вас своя реализация или от Facebook?