Когда вы засыпаете ночью, в голову лезут мысли, что, возможно, есть все-таки какой-то способ хакнуть эту защиту. А что, если кто-то использует для этого именно вас?! Возможно, вы всего лишь выдуманный персонаж фантастической истории, опубликованной с целью собрать побольше комментариев с описанием возможностей взлома… Хмм...
Конечно, есть случаи когда эти оптимизации не сработают. Но компилятор все-же обычно имеет достаточно информации, чтобы определить, что какая-то строка используется локально и временно, как один из компонент итогового результата.
Это не беспроигрышный вариант, потому что подразумевает некоторый перерасход памяти.
Сейчас, чтобы получить результат конкатенации, все равно нужно выделять память под него, а потом придется освобождать старые буфера — тут и просто расход процессора, и фрагментация памяти…
Впрочем, анализ провести лишним не будет.
Он не будет репрезентативным. Горячие места оптимизированы через использование []byte, а строки используются там, где это делать лениво или муторно. С одной стороны, хорошо, что язык позволяет более-менее эффективно работать с последовательностями байт, но это требует от программиста усилий. А компактный наглядный код остается медленным, и никто это оптимизировать не спешит, ибо сложно, да и зачем, когда те, кому сильно надо, и так сделают через []byte.
А вот как копировать только правую часть я не понял. У нас же должна новая строка в результате получиться, при этом ни один из операндов не должен изменяться.
например, выражение
buf += fmt.Sprintf(" %d", val)
либо
return(buf + fmt.Sprintf(" %d", val))
в обоих случаях тот buf что был до момента конкатенации как отдельная строка после конкатенации уже не нужен (а даже если бы и был ещё нужен — эту часть результирующей строки можно использовать как отдельную строку).
то лучше использовать какой-нибудь bytes.Buffer или strings.Builder.
Ну, есть способы, конечно (например strconv.AppendInt() вместо += strconv.Itoa(), но они заставляют программиста опускаться к деталям реализации, вместо того чтобы переложить эту работу по оптимизации на компилятор.
Не уверен, что понимаю, как это может быть возможно.
Когда мы используем
s3 = s1 + s2
то у нас выделяется память под s3 и туда копируется и s1, и s2. Хотя, если бы мы при выделении памяти под s1 зарезервировали в конце достаточно места, до было бы достаточно скопировать только s2 в конец s1, чтобы получить s3 (вот Вам и копирование только правой части — s1 не копируется, а остается в составе s3)
Или
s3 = s1 + S()
Если компилятор сможет сообщить S(), что результат надо возвращать не в отдельно выделенной памяти, а сохранить в конце s1 — тогда вообще не надо будет ничего копировать — S() сама запишет результат куда надо, останется только оформить новую строку.
Но, теоретически, можно добиться гораздо большей производительности, если научить компилятор вообще избегать копирования данных (где это можно).
Например, если компилятор видит, что к строке идет много прибавлений — он может выделить сразу большой буффер и копировать только правую (после '+') часть. Это сейчас можно делать вручную через buf = append(buf, str)), но ручную работу лучше автоматизировать.
А ещё круче будет научить компилятор заранее указывать, куда писать результат, для функции, которая возвращает строку. Тогда можно будет обойтись вообще без копирования (если этот результат нужен для того, чтобы прибавить его к строке).
Эх, мечты, мечты… ))
Известны, конечно, сам с таким сталкивался. Я не спорю, что защита контента от изменения нужная вещь. И защита от прочтения, в общем-то тоже. Просто защита от прочтения делает диагностику ошибок гораздо более сложной, только и всего.
Да решение то найдется, только все ли оно будет таким эффективным?
Я через ngrep могу быстро собрать стат по тысячам запросов и выявить аномалии, запустив shell-однострочник, составленный за минуту. Лишние движения по расшифровке трафика (а серверов может быть гораздо больше одного) заберут время и ресурсы сервера (а, следовательно, на хайлоаде и не всегда возможны), или приведут к тому, что что-то будет упущено.
В любом случае, с HTTP анализ трафика гораздо, гораздо проще чем с HTTPS.
Ну как сказать, ситуации разные бывают, и иногда посмотреть живой трафик это самый простой (и надежный, что немаловажно!) способ узнать, что происходит в реальности. Логирование может что-то упустить, а в дампе трафика все на виду.
Сисадмины обычно бекендом занимаютя.
Ну, там проверить все ли запросы приходят куда надо и с нужными параметрами, найти повторяющийся шаблон в ддос-запросах и настроить блеклистинг (mitmproxy тут не поможет, увы), проблемы у клиента, незнакомого с отладочными панелями в браузере, всякое…
«дефолт-система» это устоявшееся название? Мне кажется, тут надо что-то более выразительное придумать.
И ещё вопрос: когда человек погружен в компьютерную игру — тут какая система занята? Если игра логическая — то, видимо, аналитическая система, а если шутер? А RPG в процессе блуждания/исследования мира? А когда книжку художественную читаешь — какая?
Он просто продолжил создавать новые файлы .s, заполненные небольшими фрагментами данных, которые вставлял в произвольные места в makefile, пока они каким-то образом не перестали крашиться, после чего выпустил её!
Вместо программирования ИИ дронов, свормов и прочего автоматического оружия автору стоит реализовать возможность дать это сделать самому игроку. А мультиплеере (если вдруг появится) возможность продавать/покупать прошивки оружия с пользовательским ИИ ;)
Сейчас, чтобы получить результат конкатенации, все равно нужно выделять память под него, а потом придется освобождать старые буфера — тут и просто расход процессора, и фрагментация памяти…
Он не будет репрезентативным. Горячие места оптимизированы через использование []byte, а строки используются там, где это делать лениво или муторно. С одной стороны, хорошо, что язык позволяет более-менее эффективно работать с последовательностями байт, но это требует от программиста усилий. А компактный наглядный код остается медленным, и никто это оптимизировать не спешит, ибо сложно, да и зачем, когда те, кому сильно надо, и так сделают через []byte.
например, выражение
либо
в обоих случаях тот buf что был до момента конкатенации как отдельная строка после конкатенации уже не нужен (а даже если бы и был ещё нужен — эту часть результирующей строки можно использовать как отдельную строку).
Ну, есть способы, конечно (например strconv.AppendInt() вместо += strconv.Itoa(), но они заставляют программиста опускаться к деталям реализации, вместо того чтобы переложить эту работу по оптимизации на компилятор.
Когда мы используем то у нас выделяется память под s3 и туда копируется и s1, и s2. Хотя, если бы мы при выделении памяти под s1 зарезервировали в конце достаточно места, до было бы достаточно скопировать только s2 в конец s1, чтобы получить s3 (вот Вам и копирование только правой части — s1 не копируется, а остается в составе s3)
Или Если компилятор сможет сообщить S(), что результат надо возвращать не в отдельно выделенной памяти, а сохранить в конце s1 — тогда вообще не надо будет ничего копировать — S() сама запишет результат куда надо, останется только оформить новую строку.
Но, теоретически, можно добиться гораздо большей производительности, если научить компилятор вообще избегать копирования данных (где это можно).
Например, если компилятор видит, что к строке идет много прибавлений — он может выделить сразу большой буффер и копировать только правую (после '+') часть. Это сейчас можно делать вручную через buf = append(buf, str)), но ручную работу лучше автоматизировать.
А ещё круче будет научить компилятор заранее указывать, куда писать результат, для функции, которая возвращает строку. Тогда можно будет обойтись вообще без копирования (если этот результат нужен для того, чтобы прибавить его к строке).
Эх, мечты, мечты… ))
Я через ngrep могу быстро собрать стат по тысячам запросов и выявить аномалии, запустив shell-однострочник, составленный за минуту. Лишние движения по расшифровке трафика (а серверов может быть гораздо больше одного) заберут время и ресурсы сервера (а, следовательно, на хайлоаде и не всегда возможны), или приведут к тому, что что-то будет упущено.
В любом случае, с HTTP анализ трафика гораздо, гораздо проще чем с HTTPS.
Ну, там проверить все ли запросы приходят куда надо и с нужными параметрами, найти повторяющийся шаблон в ддос-запросах и настроить блеклистинг (mitmproxy тут не поможет, увы), проблемы у клиента, незнакомого с отладочными панелями в браузере, всякое…
И ещё вопрос: когда человек погружен в компьютерную игру — тут какая система занята? Если игра логическая — то, видимо, аналитическая система, а если шутер? А RPG в процессе блуждания/исследования мира? А когда книжку художественную читаешь — какая?
Окно свернули — винда его память подчистила сама.
Хочу ещё добавить, что не хватает ещё информации о цветовых тестах для исследования бинокулярного баланса )
«Совершенство достигается не тогда, когда нечего добавить, а тогда, когда нечего отнять».