filename.compare(filename.length() - 4, 4, ext);

Да, так красиво.

ты меня так выругал что я убрал это дерьмо и заменил на компейр

все :)

все доволны

Sorry!

за что?

все по делу

все доволны

Кроме процессора.

ну да

но я думаю это крохоборство

тут андрей прав

лучше мейнтейнебл код

Блядь😂😂

Какой злой бот

@micktu

Какой злой бот

Настроить нормально надо

фига я удивился

Не ты один :D

на самом деел разумное замечание, буду писать полновесные предложения.

Настроить нормально надо

Вообще тут было до фига флудеров. И он спасал от кучи пустых сообщений

лучше мейнтейнебл код

»> filename.compare(filename.length() - 4, 4, ext); Вот ЭТО - ни то, ни сё. И не быстро, и не "мейнтейнебл".

Кроме процессора.

на самом деле я согласен с андреем, лучше мейнтейнебл код чем сомнительныйе микрооптимизации

тем более что я знаю где боттлнек в моем приложении и он вообще не там, он в регексах.

»> filename.compare(filename.length() - 4, 4, ext); Вот ЭТО - ни то, ни сё. И не быстро, и не "мейнтейнебл".

Матвей, что бы ты предложил?

вчера я легим изменениям ускорил его в 6 раз

а еще есть место судя по профайлеру где могу ускорить вдвое

чот регексы медленные

тем более что я знаю где боттлнек в моем приложении и он вообще не там, он в регексах.

std::regex ?

угу

Они кажется не компилируются в автомат в стандартной библиотеке, поэтому так.

реально, то 80% проц. времени жрал регекс, теперь 50% два регекса суммарно

я просто прохождусь по нескольким мегбайтам текста ими...

но все равно достаочно быстро работает, так что можно не паритсья

»> filename.compare(filename.length() - 4, 4, ext); Вот ЭТО - ни то, ни сё. И не быстро, и не "мейнтейнебл".

Мне вот тот каст в uint64_t не по душе. То есть изящно, конечно, все дела, но dirty

кстати как регекс ускорился в 6 раз

Матвей, что бы ты предложил?

Исходя из требований: Надо, быстро, надо рилтайм, ай-ай-ай, время,время - тогда хак с алиасингом, но нормально обёрнутый, чтобы минимум самострела Если это веб-странички грузить - то compare, но со всеми проверками и без магической константы. А если от этого жизнь астронавта будет зависеть - ну, тогда и разговор был бы другой :)

было \r?\n

стало (\r\n)|\n

лукахед что-то очень дорогой оказался

Мне вот тот каст в uint64_t не по душе. То есть изящно, конечно, все дела, но dirty

согласен

оставшийся второй жрун процессора выглядит так \\\w+?(_([a-zA-Z]{2}))?\.dat

Когда ты держишь указатель сразу на объект внутри uniq-а то для обращения к объекту только один deref

если ты идешь по вектору unique_ptr то ты ловишь уже два а не один, + потенциальный рандом

он пробегается по всего-то 8000 файловых имен

но это самая тяжелая операция в программе

в идеале стоит заменить его на простой парсер...

если ты идешь по вектору unique_ptr то ты ловишь уже два а не один, + потенциальный рандом

Не понял.

Если ты идёшь по вектору поинтеров у тебя 1 derference

Я уже сказал об этом.

в идеале стоит заменить его на простой парсер...

а можно и на непростой

Плюс — потенциально другой алгоритм где мы ходим по нему в цикле будет работать на одну индирекцию меньше.

Вот здесь.

на ПЕГ

мне он все равно пригодится потому что ум еня свой формат есть который я сейчас паршу ОЧЕНЬ наивно

Раз уж тут упомянули парсеры, подскажите, как мне эту сишную телегу из бота для телеги переписать на модерн с++ с нормальным перфомансом

думаю можно разогнать с 20 секунд выполнения до 4-5 секунд

жопу в кресло и переписать

😂

Раз уж тут упомянули парсеры, подскажите, как мне эту сишную телегу из бота для телеги переписать на модерн с++ с нормальным перфомансом

Вопрос-то в чем, Берешь и переписываешь :D

Вопрос-то в чем, Берешь и переписываешь :D

Как

да как по мне код выше выглядит как нормальный быстрый парсер

просто некрасивый

потоум чтоо велосипед

поэтому же я гне хочу городить велосипеды вместо регексов

Тут есть еще один очень неприятный нюанс - в андроиде ндк регэкспы сломаны

Мобилкопроблемы :(

Если ты идёшь по вектору поинтеров у тебя 1 derference

изначальный посыл человека по поводу задачи я понял как: хочу линейно расположенные элементы в векторе, буду по ним часто бегать. А еще хочу извне откуда то на них ссылаться (но не бегать по ним часто). В таком случае более проищводительно будет иметь просто вектор элементов а не вектор ссылок на онные, а ссылаться уже нестандартно - оффсетом. (в всю полноты задачи не вникал, т.к. нет времени, мб оно и ненадо на самом деле)

А, эту проблему мы уже решили, да.

Просто заранее посчитаем количество элементов и переезжать не надо.

я просто хотел понять - мб я в чем то не прав

уже для себя

щас будет гениальный вопрос, господа

Речь идет о том, когда элементов неизвестное количество. То как на них ссылаться? Варианта по сути два, вектор юник_птров и ссылаться прям на объекты, или вектор значений, а для ссылки использовать сслылку на вектор и оффсет. И плюсы\минусы таких решений в зависимости от задачи.

итак: как передать реф на this?

*this

*this

черт, справедливо. какой же я пока что тугой.

сам this - это поинтер

Речь идет о том, когда элементов неизвестное количество. То как на них ссылаться? Варианта по сути два, вектор юник_птров и ссылаться прям на объекты, или вектор значений, а для ссылки использовать сслылку на вектор и оффсет. И плюсы\минусы таких решений в зависимости от задачи.

ну значит все, норм, спасибо )

да, я видел это и не догадался. очень плох

разыменовал — получил объект собсна

если что, boost::regex в несколько раз быстрее чем из стандартной библиотеки