ха... на foobar нету ошибки а на строках из файла похоже есть

Могу генератор дать, которым этот файл сгенерирован

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

это повод для мыслей мейнтейнеров, не? я с 0 опыта, напишу омерзительно медленный вариант (самый первый который был) и придется проходить по всем граблям потом что из-за опыта опять же займет не 2 дня как здесь, а неделю (и потом осточертеет скорее всего)

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

@eahqzsr там обычные строки?

Ну мне вообщет на миллионы надо.

мейнтнеры хабр что ли читают? =)

@Masteroid ну вроде особо никто не рвал

сразу сказали что не так и применив пару простых вещей получили тоже или лучше

потом уже игрались

ну так уж и "сразу"

к тому же я ничего не говорю про конкретно вас

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

одно другому не мешает

я говорю, что если писать статью, то надо определиться с посылом

@eahqzsr там обычные строки?

Ну да, байтовые строки <20 байт.

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

000a это что?

\n?

впрочем, может дерево в компакте сейчас и лучше будет

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

лучше статью "как мы раскидали вычисление по N процам" или "как мы запилили вычисление на кластере за 200 строк"

@Masteroid строков там примемрно одинаково

а как мы pypy обгоняли ещё можно

или что-то типа "о чем надо помнить если вы пишите однопоточную числодробилку"

[qnikst@nixos:~/workspace/myself/experiments/bug]$ ./test-case < test2.txt mygfc [qnikst@nixos:~/workspace/myself/experiments/bug]$ ./test-case < test.txt 5tg3emygfc [qnikst@nixos:~/workspace/myself/experiments/bug]$ hexdump test2.txt 0000000 796d 6667 2063 7435 3367 0d65 000a 000000d [qnikst@nixos:~/workspace/myself/experiments/bug]$ hexdump test.txt 0000000 796d 6667 2063 7435 3367 0a65 000000c

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

в данном случае не факт

ну на c или rust можно

но тогда и у нас есть куда идти : ]

тут же оно впирается в IO

go точно такой же garbage collected

rust - да

ну у си и раста нету трат на gc

теоретически может

да и тут уже трат практически нету

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

Оно впирается в IO-либы по процу, скорее так.

так я никак раст и не могу куда-то припахать

по розетте пошарился - код на нём мне не так уж и нравится, кстати

очень уж много писанины

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

будет со свифтом каким-нибудь соревноваться

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

Или котлин нейтив

что с ним не так-то было.

что бы хоть какую-то мораль извлечь

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

@anarchostatist тут раст обижают

если просто в первоначальный код билдер добавить и гц потюнить то он где-то раз в 7 уже ускорится, остальное добирание каких-то крох

>как средний язык

кк

"используйте StringBuilder" - практически первый совет, который давали тем, кто начинал учить джаву в 2002-ом году

StringBuffer

"используйте StringBuilder" - практически первый совет, который давали тем, кто начинал учить джаву в 2002-ом году

с 8ки это уже не требуется, работает под капотом (иногда еще и быстрее оптимизируется если руками не лезть)

@anarchostatist ну в него никогда не будут вкладывать столько труда сколько в кланг, меньше чем в свифт и побольше чем в Ди, но не принципиально. Конечно больше, чем в млтоны всякие, вот их он будет эффектно побеждать

спекуляции не нужны

это ЭКСПЕРТНАЯ ОЦЕНКА

@voidlizard только вот в яве то наверняка конкатенация строк так и работает, так что аналогичная ситуация и не возникла бы

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

впрочем этот билдер с явовским мало общего имеет

и что на комп поставить

и отказываюсь от этой мысли

вот если кто-то напишет на расте было бы гран-мерси

тупо самую простую версию

ау, есть кто-то кто владеет? на х-ле первый вариант писался за пару минут

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

а на жабе код не пишут, только поддерживают 😀

https://github.com/fitzgen/rust-words/tree/master/src

вашу ж офелию. вот поэтому мы и пишем на хаскеле

вот особенно поэтому https://github.com/fitzgen/rust-words/blob/master/src/word_reader.rs

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

там сложность только в тестировании потому что стартует jvm относительно долго + jit хочет прогрев

вот если кто-то напишет на расте было бы гран-мерси

что написать?

считать пары "префикс суффикс" из stdin, для каждого префикса сгенерить все суффиксы и записать все получившиеся пары в stdout

в той репе треш какой-то

ээ, очень многозначно

декартово вроде

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

префикс это до пробела?

какой

https://gist.github.com/voidlizard/2c986d1892d87d90bbcc1126ca72dbff

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

префикс это до пробела?

считать файл (N строк) pref1 suff1 pref2 suff2 ... prefN suffN вывести файл (N^2 строк) pref1suff1 pref1suff2 ... pref2suff1 pref2suff2 ...

как-то так было