Во-первых, "это" не форум.
Во-вторых, здесь вы уже ничего не опубликуете.
В-третьих, это не велосипед, а деревянная палка, к которой вместо колес примотаны скотчем костыли.
Для умной и конструктивной дискуссии приходите на Тостер и задавайте вопросы о том, как правильно работать с SQL. Для начала про защиту от SQL инъекций. Воможно, годика через два, у вас и получится что-то, что будет не стыдно показать другим разрботчикам, и надеяться на "конструктивную дискуссию"
Ну так эти пара тактов размазываются на сотни тысяч вызовов кэшированного кода.
Разницу между "50\$" vs '50$' я бы не назвал субъективной, но если вам так хочется, то могу снять это предложение, оно не имеет для меня ни малейшей ценности. Вопрос не в том, какой ещё аргумент посчитать объективным, а в том, что "пара тактов" таковым не является.
ЗЫ. Я бы не был настолько тошнотворно-серьезен, если бы этот миф не был настолько живуч.
Даже в отчаянных попытках натянуть сову на глобус, в бесстыдно синтетических тестах без какой-либо полезной нагрузки вообще, по приведенным выше ссылкам получается 8.55% в прыжке.
Любая полезная нагрузка эту цифру только уменьшит, причем катастрофически.
То есть ваши 10% на приложение — это либо ошибка, либо вы одновременно оптимизировали что-то ещё — ту самую полезную нагрузку. Что является куда более реальным сценарием.
Беда вашего комментария в том, что вы прочитали из моего примера только одну строчку, а надо было — весь пример целиком ;-)
В РНР действительно идиотский механизм неявного преобразования типов, но приведенный выше пример как раз и является успешной попыткой эту ситуацию исправить.
Ну, я пока не видел приложения, которое показало бы стабильный измеряемый и подтверждаемый прирост производительности в 0.6% (6 процентов от 10 процентов) от добавления слешей перед вызовами функций. Когда увижу — тогда соглашусь — да, эта оптимизация стоит моего внимания.
До тех пор я буду по-старинке — сначала профилировать, потом оптимизировать. А не наоборот.
Ну написано же, что даже не на пару тактов :)
В опкод кэше все строки равны. Идентичны. Эквивалентны. Нету там пары тактов.
Аргумент этот какой угодно, но не объективный. Учитывая живучесть мифа — так даже и вредный.
На объективный тянет другой аргумент, который приводили ниже — тупо удобство работы со спецсимволами.
Ну вот опять это лукавство :)
10% не от общего времени исполнения кода, а от времени, которое затрачивается на вызов функций. А сколько его там затрачивается?
Никак не буду мерить :)
В статье ясно сказано — оптимизировать надо то, что в тормозит в реальности, а не в чьём-то в воображении — и я с этим согласен.
На вызовы функций приходится 0.000...% общего времени исполнения кода. Ускорение этого участка на 5% я при всем желании не замечу.
Если моя программа работает медленно, то самое последнее, чем я буду заниматься — это пририсовывать палочки к вызовам функций.
Ну опять же — никаким приростом уровня приложения тут и не пахнет. Я тут вижу стандартный вывод phpbench, тупо вызывающего по 10 тыщ раз одну и ту же функцию, не делающую ничего.
Все в точности, как говорится в статье выше — если только заставить эти несчастные подопытные функции выполнять хоть какую-то полезную работу, то все эти проценты улетучатся, как белых яблонь дым.
Ну вот опять же, "множество" — это сколько? Может, лучше уменьшить это множество, чем оптимизировать его? Сколько должно быть этих мелких вызовов, чтобы разница стала хотя бы на пределе чувствительности радара ощущаться?
Ну вот кстати я бы посмотрел на реальный проект, который был ускорен таким способом.
Причем именно на проект целиком, а не на специально написанный цикл на 100500 итераций :)
Мне кажется, это зависит от предназначения функции. Если это проверка, которая и должна вернуть 0 или 1 в зависимостиот переданного параметра, то исключение не нужно.
А если функция должна как-то обработать и вернуть введенное значение, то исключение — это как раз идеальный способ сообщить об ошибке. Но это будет именно ошибка, а не результат работы.
Честно говоря, в РНР это делается простым условием. Если, скажем, мы ожидаем int, то
$int = filter_var($raw_input, FILTER_VALIDATE_INT);
if (is_int($int)) {
// число, производим операции над $int
} else {
// в $raw_input строка, парсим её
}
Да, я согласен. Сам такого не видел, но слышал, что иногда throw используется тупо как замена goto, и в итоге throw используется при штатном выполнении кода, а не только при возникновении ошибок. Но что характерно — здесь опять же, в первую очередь это bad design, а уже во вторую — производительность. То есть, плохой код надо исправлять потому что он плохой, а не потому что он на пару миллисекунд медленнее.
Так в том-то и дело что и не должны помнить. Это будет счастье, если вырастет такое поколение. Поскольку сама постановка вопроса неверная, а единственное, что показывают такие тесты — это криворукость тестировщика.
Основных проблем две: мало того что сами тесты не имеют ни малейшего смысла, и несут только вред — но автор при этом еще и умудряется накосячить в каждом конкретном тесте, сравнивая теплое с мягким и хронометрируя несуществующий код. Это если внимательно вчитаться в код и пояснения к каждому тесту, а не просто смотреть на цыферки результатов.
Ну, строго говоря, чтобы использовать повседневно, все равно придется заворачивать вызов в отдельную функцию — не писать же каждый раз эту простыню. А с отдельной функцией и сейчас можно исключение бросить.
Во-первых, "это" не форум.
Во-вторых, здесь вы уже ничего не опубликуете.
В-третьих, это не велосипед, а деревянная палка, к которой вместо колес примотаны скотчем костыли.
Для умной и конструктивной дискуссии приходите на Тостер и задавайте вопросы о том, как правильно работать с SQL. Для начала про защиту от SQL инъекций. Воможно, годика через два, у вас и получится что-то, что будет не стыдно показать другим разрботчикам, и надеяться на "конструктивную дискуссию"
Ну так эти пара тактов размазываются на сотни тысяч вызовов кэшированного кода.
Разницу между "50\$" vs '50$' я бы не назвал субъективной, но если вам так хочется, то могу снять это предложение, оно не имеет для меня ни малейшей ценности. Вопрос не в том, какой ещё аргумент посчитать объективным, а в том, что "пара тактов" таковым не является.
ЗЫ. Я бы не был настолько тошнотворно-серьезен, если бы этот миф не был настолько живуч.
Я посчитал.
Извините, но я не верю.
Даже в отчаянных попытках натянуть сову на глобус, в бесстыдно синтетических тестах без какой-либо полезной нагрузки вообще, по приведенным выше ссылкам получается 8.55% в прыжке.
Любая полезная нагрузка эту цифру только уменьшит, причем катастрофически.
То есть ваши 10% на приложение — это либо ошибка, либо вы одновременно оптимизировали что-то ещё — ту самую полезную нагрузку. Что является куда более реальным сценарием.
В любом случае, я бы хотел увидеть тесты.
Беда вашего комментария в том, что вы прочитали из моего примера только одну строчку, а надо было — весь пример целиком ;-)
В РНР действительно идиотский механизм неявного преобразования типов, но приведенный выше пример как раз и является успешной попыткой эту ситуацию исправить.
Ну, я пока не видел приложения, которое показало бы стабильный измеряемый и подтверждаемый прирост производительности в 0.6% (6 процентов от 10 процентов) от добавления слешей перед вызовами функций. Когда увижу — тогда соглашусь — да, эта оптимизация стоит моего внимания.
До тех пор я буду по-старинке — сначала профилировать, потом оптимизировать. А не наоборот.
Ну написано же, что даже не на пару тактов :)
В опкод кэше все строки равны. Идентичны. Эквивалентны. Нету там пары тактов.
Аргумент этот какой угодно, но не объективный. Учитывая живучесть мифа — так даже и вредный.
На объективный тянет другой аргумент, который приводили ниже — тупо удобство работы со спецсимволами.
Ну вот опять это лукавство :)
10% не от общего времени исполнения кода, а от времени, которое затрачивается на вызов функций. А сколько его там затрачивается?
Никак не буду мерить :)
В статье ясно сказано — оптимизировать надо то, что в тормозит в реальности, а не в чьём-то в воображении — и я с этим согласен.
На вызовы функций приходится 0.000...% общего времени исполнения кода. Ускорение этого участка на 5% я при всем желании не замечу.
Если моя программа работает медленно, то самое последнее, чем я буду заниматься — это пририсовывать палочки к вызовам функций.
Ну опять же — никаким приростом уровня приложения тут и не пахнет. Я тут вижу стандартный вывод phpbench, тупо вызывающего по 10 тыщ раз одну и ту же функцию, не делающую ничего.
Все в точности, как говорится в статье выше — если только заставить эти несчастные подопытные функции выполнять хоть какую-то полезную работу, то все эти проценты улетучатся, как белых яблонь дым.
Так в том-то и дело что он даже и это посчитать не может :)
Ну вот опять же, "множество" — это сколько? Может, лучше уменьшить это множество, чем оптимизировать его? Сколько должно быть этих мелких вызовов, чтобы разница стала хотя бы на пределе чувствительности радара ощущаться?
Ну да, логично. Поскольку в пхп типизации вообще, по сути, никакой, то можно приводить что угодно к чему угодно, и это не будет ошибкой.
ошибся с ответом
Ну вот кстати я бы посмотрел на реальный проект, который был ускорен таким способом.
Причем именно на проект целиком, а не на специально написанный цикл на 100500 итераций :)
Мне кажется, это зависит от предназначения функции. Если это проверка, которая и должна вернуть 0 или 1 в зависимостиот переданного параметра, то исключение не нужно.
А если функция должна как-то обработать и вернуть введенное значение, то исключение — это как раз идеальный способ сообщить об ошибке. Но это будет именно ошибка, а не результат работы.
Честно говоря, в РНР это делается простым условием. Если, скажем, мы ожидаем int, то
или я неверно понял задачу
Да, я согласен. Сам такого не видел, но слышал, что иногда throw используется тупо как замена goto, и в итоге throw используется при штатном выполнении кода, а не только при возникновении ошибок. Но что характерно — здесь опять же, в первую очередь это bad design, а уже во вторую — производительность. То есть, плохой код надо исправлять потому что он плохой, а не потому что он на пару миллисекунд медленнее.
Так в том-то и дело что и не должны помнить. Это будет счастье, если вырастет такое поколение. Поскольку сама постановка вопроса неверная, а единственное, что показывают такие тесты — это криворукость тестировщика.
Вот разбор косяков подобных "тестов", как раз на примере данной статьи, https://phpdelusions.net/articles/single_vs_double
Основных проблем две: мало того что сами тесты не имеют ни малейшего смысла, и несут только вред — но автор при этом еще и умудряется накосячить в каждом конкретном тесте, сравнивая теплое с мягким и хронометрируя несуществующий код. Это если внимательно вчитаться в код и пояснения к каждому тесту, а не просто смотреть на цыферки результатов.
Ну, строго говоря, чтобы использовать повседневно, все равно придется заворачивать вызов в отдельную функцию — не писать же каждый раз эту простыню. А с отдельной функцией и сейчас можно исключение бросить.
Но новость все равно очень оптимистичная