dmz@zen ~/tmp/bsfuck $ time ./v-stream < ./49zGQ6Zt.txt > /dev/null real 0m1.635s user 0m1.612s sys 0m0.024s

не

Как?

input.read_to_string(&mut input) и вместо lines.iter() input.split('\n')?

но уже быстрее идеоматичного хаскеля

v-stream это уже жескач.

буферизацию вывода запили

input.read_to_string(&mut input) и вместо lines.iter() input.split('\n')?

Не знаю даст ли это что-то. Попробую

input.read_to_string(&mut input) и вместо lines.iter() input.split('\n')?

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

чтобы чанки побольше были

А эту кучу строк непонятно как там jemalloc раскидывает

если write_all этого не делает

на чем остановились?

зач там буферизация

даже в си в это упирается

пишешь в буффер где-нибудь 110000 байт (константа из питона)

как накопится - дампишь

зач там буферизация

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

show next the strace :)

s/next/me/

кто такие эти все collect unwrap и lock

unwrap - это типа нашего fromJust

или fromRight

collect это fromList

lock типа unsafeFreeze

зач там буферизация

короче если проставить профилирование, то парсинг ввода занимает 7 мс

остальное вывод

это везде так

потому что ввод там мелкий

а вот выхлоп большой

да

в общем, буферизуйте вывод или какой-либо билдер/врайтер и обгоните

unwrap - это типа нашего fromJust

оно же partial function?

да

Я обогнал хаскел

а этот большой вектор за буферизацию не считается?

В воображении

в него же выхлоп и пишется

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

Cпс, выиграл у себя еще 30мс

ооо

чего-то не пойму, он все в вектор накапливает и разом пишет что-ли?

ой точно

я просмотрел

игнорируйте меня

это не годится

согласен

как лучше?

пиши порциями, как все нормальные

там получается квадрат от размера входа?

порциями

а какого размера порции

у нас плюсовая прога такая была, работала тоскливо

сделать буффер, как не может екстенднуться то флашить

кстати встроенный буфер вройте и правда говно какое-то

у питона 110000

питон тоже околеет на большом вводе? или тоько вторая версия, с join которая?

во всяком случае такими кусками он write делал

которая с join может и околеет

хз там умный jit

нет, там всё ок

это не годится

Почему?

у него AI и он дагадается по кускам писать

for p in pref: print "\n".join([(p + s) for s in suff])

всё ок

размер вектора N^2

обычно все зависимости большие NlogN это значит что взорвется на достаточно большом входе

тот, кто задавал вопрос по производительности просто такой входной файл подготовил, он собирался писать вроде сотни гигов при небольшой доступной памяти

у питона 110000

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

ну pypy дал очень хорошие результаты

не все люди на си и плюсах его сходу обогнали

только если без буфферинга вообще

про малую память, сейчас все решения минимум O(N) по памяти

т.к. минимум половину входных данных надо помнить

плюсы ничего не обогнали

dmz@zen ~/tmp/bsfuck $ time ./fu2.py < ./49zGQ6Zt.txt > /dev/null real 0m4.655s user 0m4.620s sys 0m0.032s dmz@zen ~/tmp/bsfuck $ g++ --std=c++11 -O2 ./fuck.cc -o fuck dmz@zen ~/tmp/bsfuck $ time ./fuck < ./49zGQ6Zt.txt > /dev/null real 0m5.738s user 0m5.708s sys 0m0.028s

рили? в чем там проблема?

cout в цикле 100500 сисколлов

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

либо все в один выхлопной буфер и OOM

но тоже долго