The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Отчёт о развитии FreeBSD за первый квартал 2020 года"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Подсказка: Доступны два режима работы форума: "Раскрыть нити" и "Свернуть нити".
. "Отчёт о развитии FreeBSD за первый квартал 2020 года" +/
Сообщение от Ordu (ok), 14-Апр-20, 22:54 
> Быстрее не будет, потому что быстрее физически невозможно, не нарушая условия.

Если физически невозможно, не нарушая условия, то можно даже не заморачиваться на оптимизацию. Оптимизация возможна только тогда, когда есть физическая возможность.

> Все вопросы к автору jq, я не могу его ускорить.

Ты не пробовал. Возьми профайлер и выясни почему он тормозит. Когда ты поймёшь почему, тогда можно будет рассуждать о существовании или несуществовании возможности ускорить.

Хотя, с учётом дополнительной капли информации о задаче, которую ты выдал, я уже даже не знаю, что предположить. Я начинаю подозревать, что проблема в твоём коде: bison никоим образом нельзя назвать генератором самых быстрых парсеров, но всё же его парсеры неплохи в смысле производительности. Можно допустить что jq использует bison как-то не так, но мне это кажется менее вероятным, чем то, что ты jq используешь как-то не так. И если делать ставки, то (учитывая "запросы жсона из тысяч жсона и мешок регулярок") я бы поставил на то, что ты решаешь задачу на уровне json'а, хотя следовало бы решать её на уровне данных -- то есть парсить json в данные, работать с данными, а потом сериализовать эти данные в json. Реально попробуй весь этот json складывать в sqlite, и потом выполнять основной процессинг данных на языке программирования SQL. Кстати, если я угадал в чём дело, то python может оказаться быстрее C. Если я прав в своих предположениях, то можно и без sql сделать, но там тебе ручками придётся создавать индексы, жонглировать хеш-табличками -- в C примерно так же сложно, как пользоваться SQL, поэтому в любом случае лучше взять python, ruby, go, rust, или C++ на крайняк... что-нибудь из этого списка взять и сделать там.

Я повторю ещё раз: 20 секунд на 500 строк -- это уровень производительности пристойный для 70-х годов. Если низкоуровневая оптимизация компилятора применяемая к strcpy может уменьшить эти 20 секунд до 19, то вместо того, чтобы перебирать компиляторы и флаги к ним, тебе следует объявить strcpy своим личным врагом и выкинуть из программы хотя бы 90% вызовов strcpy, заменив их чем-нибудь другим. Тогда твои 20 секунд уменьшатся сразу до 5 секунд или даже вообще превратятся в виртуальный 0 секунд, потому как твоя психика будет воспринимать время работы программы как моментальное.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Отчёт о развитии FreeBSD за первый квартал 2020 года, opennews, 13-Апр-20, 16:16  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру