Но, при этом, маршрут к содовой и обратно был заранее запланирован. Т.е. «пойди в конкретное место, найди там банку содовой, возьми её, пойди в конкретное место 2».
Справедливости ради нужно отметить, что эти расходы минимальны пока вы не начинаете делать очень активное IO. При очень высоком IO докер может добавлять прилично дополнительных расходов.
Да. 32-bit Java — всё :(
Оракл решил не тратить время на тестирование под 32bit платформы.
При желании можно собрать себе OpenJDK под 32bit и получить почти то же самое. Изменений, блокирующих работу на 32bit в Java нет. Только отсутствие официальной поддержки.
PS: Когда Java 9 только релизнулась, на офф. сайте была 32bit версия, но её быстро выпилили и сказали, что выложили по ошибке :)
Там произошли изменения по способу формирования релизов. Теперь вместо набора фич, который иногда могут пилить очень долго, будут каждые N месяцев выпускать всё то, что получилось закончить и довести до ума. Так что да, Java теперь будет выходить чаще.
А еще, возможно, это будет не «Java 10». А что-то типа «Java 18.3» (год и месяц).
Ну был бы протокол открытый. Ну накосячил бы разработчик какой-то базовой используемой всеми либы (открытой!) для реализации этого протокола — точно так же могли бы лечь все. Открытость сама по себе не спасает от ошибок. Тот же OpenSSL (Heartbleed) вспомните.
Почему вы уверены, что в случае с регекспом там будет такая же сложность? Ведь регекспу нужно уметь и с другими сценариями работать. Там почти наверняка будет не просто префиксное дерево (если вообще оно), а множество дополнительных проверок, которые в данном случае будут работать вхолостую.
встроенная реализация языка наверняка оптимизирована гораздо лучше, чем то, что напишу я
Очень распространенное заблуждение. «Если что-то есть в стандартной либе, то оно там жутко заоптимизировано под все случаи жизни». Если у вас более специализированное решение «заточенное» под конкретный сценарий, то очень часто можно получить огромную прибавку в производительности. Особенно если решение имеет лучшую оценку сложности.
А в случае питона она наверняка будет ещё и не на байткоде, а на си, что ускорит её ещё больше.
В случае с питоном — может быть. Но на самом деле не обязательно: есть же всякие PyPy и прочие.
В таком случае у автора был выбор: написать с нуля свою библиотеку, или же взять готовую библиотеку построения префиксных деревьев и сконвертировать её выдачу в регексп. Второй вариант мне кажется правильнее.
Чем же вам не угодил самый логичный вариант — выполнить поиск с помощью этого самого префиксного дерева? Зачем префиксное дерево конвертировать в регексп, а потом из регекспа обратно в перфиксное дерево?
То, что вы предлагаете — это уж точно не «готовый и простой в использовании инструмент», так как построить регексп, соответствующий по структуре префиксному дереву — это даже чуточку сложнее, чем строить само префиксное дерево. Больше похоже на предложение забивать гвозди «простой в использовании» микроскопом :)
И это при том, что пока что нет гарантий, что такой регексп в конкретной реализации будет работать эффективно.
С английского: interference — помехи, вмешательство.
Видимо, идея в том, что на старом железе вам вряд ли особо понадобится новый софт на Java. В любом случае — Оракл просто сокращает расходы.
Оракл решил не тратить время на тестирование под 32bit платформы.
При желании можно собрать себе OpenJDK под 32bit и получить почти то же самое. Изменений, блокирующих работу на 32bit в Java нет. Только отсутствие официальной поддержки.
PS: Когда Java 9 только релизнулась, на офф. сайте была 32bit версия, но её быстро выпилили и сказали, что выложили по ошибке :)
А еще, возможно, это будет не «Java 10». А что-то типа «Java 18.3» (год и месяц).
В случае с питоном — может быть. Но на самом деле не обязательно: есть же всякие PyPy и прочие.
И это при том, что пока что нет гарантий, что такой регексп в конкретной реализации будет работать эффективно.