Так ведь прокси-объекты у нас создавались и раньше, не? Например, если в объекте использовалась ленивая загрузка сущностей (кстати оттуда же старая песня, что getter’ы сущностей не могут быть final — та же проблема, что и с CDI объектами, требующими специфичного функционала — например, нельзя из final методов юзать инжектируемые поля класса)
А что мешает при нахождении первого совпадающего символа получить следующий, и, если оба совпали, просто глянуть забрать по индексу последний чар искомой подстроки — и при его совпадении уже сравнить эту последовательность? Быстрее, чем по одному символу перебирать, не будучи уверенным в том, что мы все же в искомой подстроке.
Что Вы хотите от статьи, написанной GPT? Там же с первого абзаца прям попахивает :)
Так ведь прокси-объекты у нас создавались и раньше, не? Например, если в объекте использовалась ленивая загрузка сущностей (кстати оттуда же старая песня, что getter’ы сущностей не могут быть final — та же проблема, что и с CDI объектами, требующими специфичного функционала — например, нельзя из final методов юзать инжектируемые поля класса)
А что мешает при нахождении первого совпадающего символа получить следующий, и, если оба совпали, просто глянуть забрать по индексу последний чар искомой подстроки — и при его совпадении уже сравнить эту последовательность? Быстрее, чем по одному символу перебирать, не будучи уверенным в том, что мы все же в искомой подстроке.
Не совсем корректный пример, как мне кажется.
Здесь оптимальнее было бы использовать не очереди, а простой проход по массиву с получением значения «с другой стороны» до первого нарушения условия.
Думаю, лучше бы зашел пример с организацией кэша.
Заводить контейнер под каждый тест-кейс? Звучит как очень сомнительное решение и способ слить кучу денег просто на инфраструктуру.
Как и поднимать новые контейнеры для компиляции. Да и сам перфоманс такого решения где-то на уровне голубиной почты.