Исходная статья полезная, но пожалуйста, если русский язык для вас родной, вычитайте этот текст на свежую голову, и исправьте хотя бы согласование членов предложения. Глаза болят читать все эти "жонглирование типа", "поддержку, которое". Про смысловые ляпы я уж молчу. Понять смысл предложения "Это может пригодиться, когда вы понимаете, как происходят преобразования" можно только мысленно переведя обратно на английский.
Если же не родной, то, возможно, вам пока рано заниматься переводами на русский.
Я думаю что Хабр — не очень подходит для такой дискуссии. Тостер или пхпклуб или реддит подойдут больше.
Но в любом случае надо гораздо четче формулировать свои мысли — как предпосылки, так и предложения.
Три куцых абзаца после многообещающего спойлера "давайте заглянем внутрь" вызывают недоумение.
"Рецензия" написана левой пяткой за 5 минут, даже фамилия автора книги не указана. По стилю это фактически коммент в ВК, а не публикация на Хабре. Или — даже скорее — платные отзывы на Маркете.
Вы счастливый человек, что основное время при разработке у вас занимает написание кода, а не размышления, какой именно код написать. И экономия нажатия двух кнопок значительно повычит скорость разработки.
Во-первых, "это" не форум.
Во-вторых, здесь вы уже ничего не опубликуете.
В-третьих, это не велосипед, а деревянная палка, к которой вместо колес примотаны скотчем костыли.
Для умной и конструктивной дискуссии приходите на Тостер и задавайте вопросы о том, как правильно работать с SQL. Для начала про защиту от SQL инъекций. Воможно, годика через два, у вас и получится что-то, что будет не стыдно показать другим разрботчикам, и надеяться на "конструктивную дискуссию"
Ну так эти пара тактов размазываются на сотни тысяч вызовов кэшированного кода.
Разницу между "50\$" vs '50$' я бы не назвал субъективной, но если вам так хочется, то могу снять это предложение, оно не имеет для меня ни малейшей ценности. Вопрос не в том, какой ещё аргумент посчитать объективным, а в том, что "пара тактов" таковым не является.
ЗЫ. Я бы не был настолько тошнотворно-серьезен, если бы этот миф не был настолько живуч.
Даже в отчаянных попытках натянуть сову на глобус, в бесстыдно синтетических тестах без какой-либо полезной нагрузки вообще, по приведенным выше ссылкам получается 8.55% в прыжке.
Любая полезная нагрузка эту цифру только уменьшит, причем катастрофически.
То есть ваши 10% на приложение — это либо ошибка, либо вы одновременно оптимизировали что-то ещё — ту самую полезную нагрузку. Что является куда более реальным сценарием.
Беда вашего комментария в том, что вы прочитали из моего примера только одну строчку, а надо было — весь пример целиком ;-)
В РНР действительно идиотский механизм неявного преобразования типов, но приведенный выше пример как раз и является успешной попыткой эту ситуацию исправить.
Ну, я пока не видел приложения, которое показало бы стабильный измеряемый и подтверждаемый прирост производительности в 0.6% (6 процентов от 10 процентов) от добавления слешей перед вызовами функций. Когда увижу — тогда соглашусь — да, эта оптимизация стоит моего внимания.
До тех пор я буду по-старинке — сначала профилировать, потом оптимизировать. А не наоборот.
Ну написано же, что даже не на пару тактов :)
В опкод кэше все строки равны. Идентичны. Эквивалентны. Нету там пары тактов.
Аргумент этот какой угодно, но не объективный. Учитывая живучесть мифа — так даже и вредный.
На объективный тянет другой аргумент, который приводили ниже — тупо удобство работы со спецсимволами.
Ну вот опять это лукавство :)
10% не от общего времени исполнения кода, а от времени, которое затрачивается на вызов функций. А сколько его там затрачивается?
Нововведения?
Исходная статья полезная, но пожалуйста, если русский язык для вас родной, вычитайте этот текст на свежую голову, и исправьте хотя бы согласование членов предложения. Глаза болят читать все эти "жонглирование типа", "поддержку, которое". Про смысловые ляпы я уж молчу. Понять смысл предложения "Это может пригодиться, когда вы понимаете, как происходят преобразования" можно только мысленно переведя обратно на английский.
Если же не родной, то, возможно, вам пока рано заниматься переводами на русский.
Я думаю что Хабр — не очень подходит для такой дискуссии. Тостер или пхпклуб или реддит подойдут больше.
Но в любом случае надо гораздо четче формулировать свои мысли — как предпосылки, так и предложения.
Если честно, то я ничего не понял.
Речь идет о запрещении использования $_GLOBALS и global?
Три куцых абзаца после многообещающего спойлера "давайте заглянем внутрь" вызывают недоумение.
"Рецензия" написана левой пяткой за 5 минут, даже фамилия автора книги не указана. По стилю это фактически коммент в ВК, а не публикация на Хабре. Или — даже скорее — платные отзывы на Маркете.
Речь не про язык, а про статью, которую вы переводили.
Для вашего удобства я цитировал ранее предложение из неё, с которым я не согласен.
...
"У Рабиновича было собственное мнение, но он его категорически не разделял" :)
Боюсь, вы не совсем поняли статью, которую переводили.
Для вашего удобства я выше процирировал код из неё.
Дадад, и писать каждый раз эту колбасу
вместо
f<tab>myMethod()это два нажания клавиши.Вы счастливый человек, что основное время при разработке у вас занимает написание кода, а не размышления, какой именно код написать. И экономия нажатия двух кнопок значительно повычит скорость разработки.
Об этом и речь. Банальный lazy load преподносится в 1С как космическая технология.
В доктрине это все есть
Во-первых, "это" не форум.
Во-вторых, здесь вы уже ничего не опубликуете.
В-третьих, это не велосипед, а деревянная палка, к которой вместо колес примотаны скотчем костыли.
Для умной и конструктивной дискуссии приходите на Тостер и задавайте вопросы о том, как правильно работать с SQL. Для начала про защиту от SQL инъекций. Воможно, годика через два, у вас и получится что-то, что будет не стыдно показать другим разрботчикам, и надеяться на "конструктивную дискуссию"
Ну так эти пара тактов размазываются на сотни тысяч вызовов кэшированного кода.
Разницу между "50\$" vs '50$' я бы не назвал субъективной, но если вам так хочется, то могу снять это предложение, оно не имеет для меня ни малейшей ценности. Вопрос не в том, какой ещё аргумент посчитать объективным, а в том, что "пара тактов" таковым не является.
ЗЫ. Я бы не был настолько тошнотворно-серьезен, если бы этот миф не был настолько живуч.
Я посчитал.
Извините, но я не верю.
Даже в отчаянных попытках натянуть сову на глобус, в бесстыдно синтетических тестах без какой-либо полезной нагрузки вообще, по приведенным выше ссылкам получается 8.55% в прыжке.
Любая полезная нагрузка эту цифру только уменьшит, причем катастрофически.
То есть ваши 10% на приложение — это либо ошибка, либо вы одновременно оптимизировали что-то ещё — ту самую полезную нагрузку. Что является куда более реальным сценарием.
В любом случае, я бы хотел увидеть тесты.
Беда вашего комментария в том, что вы прочитали из моего примера только одну строчку, а надо было — весь пример целиком ;-)
В РНР действительно идиотский механизм неявного преобразования типов, но приведенный выше пример как раз и является успешной попыткой эту ситуацию исправить.
Ну, я пока не видел приложения, которое показало бы стабильный измеряемый и подтверждаемый прирост производительности в 0.6% (6 процентов от 10 процентов) от добавления слешей перед вызовами функций. Когда увижу — тогда соглашусь — да, эта оптимизация стоит моего внимания.
До тех пор я буду по-старинке — сначала профилировать, потом оптимизировать. А не наоборот.
Ну написано же, что даже не на пару тактов :)
В опкод кэше все строки равны. Идентичны. Эквивалентны. Нету там пары тактов.
Аргумент этот какой угодно, но не объективный. Учитывая живучесть мифа — так даже и вредный.
На объективный тянет другой аргумент, который приводили ниже — тупо удобство работы со спецсимволами.
Ну вот опять это лукавство :)
10% не от общего времени исполнения кода, а от времени, которое затрачивается на вызов функций. А сколько его там затрачивается?