dmz@zen ~/tmp/bsfuck $ time ./qnikst5 < ./49zGQ6Zt.txt > /dev/null real 0m0.371s user 0m0.368s sys 0m0.000s

офигеть

блин, почему у меня медленнее

разница только в выхлопе, без него 0.015

у тебя буффер умнее

или константы другие

просто у меня после последнего изменения и 0.40 до 0.18 прыгнуло

я ВОООБЩЕ не понимаю как это может быть

char out_buf[BUF_SIZE]; -> char out_buf[BUF_SIZE+8] ускоряет в полтора 2 раза

а нет

это мне спать пора

все нормально

@voidlizard ещё можешь попробовать сделать как у меня

if (len >8) {memcpy(,,len)}else{memcpy(,,8)}

если гарантировано что не вылезаешь за память

у меня гарантировано не вылезаешь

м, перезатирать чт ли? делать memcpy(8), а добавдять сколько там было?

да

dmz@zen ~/tmp/bsfuck $ time ./fixchunks < ./49zGQ6Zt.txt > /dev/null real 0m0.438s user 0m0.432s sys 0m0.008s

0.410 и наврнео, надо спать

если я добавлю таб ничего особо не поменяет

олимпиада получилась очень специальной

хм.. а у тебя что хранится отступ и длина?

более специальной, чем обычно

у меня сами чанки хранятся

а вижу

ну тогда из-за этого наверное, ты ж их копируешь?

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

я то не модифицирую то что пришло

только один раз

просто индекс строю

а, понятно

ты читаешь в растущий буфер

оно без realloc у тебя?

прям как есть

да

у меня хитрее

ну я могу сделать lazy-bytestring из буфферов

т.е если помещается - то читается прям в ячейку, а если нет - то хранится указатель

а не, не могу

угу

и тогда зовется реаллок для чанка. но поскольку они тут 5, то всегда помещается

а ты реаллок этого хранилища делаешь когданить?

да, много раз

а ну тогда сравнимо должно быть

может, надо поменьше

в общем я знаю как моё ускорить

но не буду, хотя просто

вообще не влияет

нужно не в растущий буффер читать, а в linked list буфферов

все равно я индекс строю потом отдельно

но тут не влияет тут файл в буффер помещается

там на чтение что-то типа 0.015

а ясн

хотя разница как раз где-то на эти миллисекунды

между двумя решениями, я имею ввиду

ага

хм получается на моем компе разница с Haskell в 10 раз

это печальненько немного

с другой стороны в сторону вложено гораздо больше времени даже на такую тривиальщину

https://paste.pound-python.org/show/fg5hdWv46KurkkDUdnxg/

ого

че

Duff device

че

в последней версии это закоментировно

там выше обсуждение, что компилятор умеет заменять memcpy с константой на специализацию более эффективную

но сам так проверку не разворачивает

убираю strchr, получаю 0.360 - 0.410 и выхожу. надо завязывать с этой токсичной темой. Отрыв от Rust - в 4 раза. https://gist.github.com/voidlizard/4dd7941d98b557a39e251109340335bf

да, уже какие-то копейки пошли

дальше только убирание realloc-ов всех но это важно на больших файлах только

0.360 это уже всего на 20% медленнее, чем просто записать нулей из /dev/zero

да. на больших, кстати, начинает тормозить

vmsplice и прочее не оправдалось

оно конечно O(N) но амортизировано

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

ну нужно linked-list буфферов

все остальное останется таким же, только for { for на выводе посложнее будет

у меня же где-то валяется, я это уже сделал

нунахер!!

вот да

хватит.