В способности выжать из железа максимум они зачастую оказывают взращенных в краю полупроводникового производства тайваньцев, и талантов из США, которым разработчики процессоров приходятся «отечественными производителями».
мне проще задержаться на полчаса на работе — ваш тезис
Вывод — ваша статья занимает полчаса рабочего времени, поскольку вы сравнили эти две стоимости.
И, да, даже в доналоговом виде это все равно очень и очень хорошо :)
P.S. Если бы фигурировала фраза «мне проще несколько раз задержаться на полчаса», то все было бы иначе
Так и быть, просвещу Вас: в Java строки иммутабельны
Это может иметь значение в определенных ситуациях.
Формулу стоимости обсуждаемой операции в общем виде можно выразить примерно так
cost = N*CA+BR*CR+BW*CW
где
N — количество вызовов аллокации блока
CA — стоимость аллокации блока.
BR — количество блоков, которые требуется прочитать
CR — стоимость чтения блока.
BW — количество блоков которые требуется записать
CW — стоимость записи блока.
Так вот по вашим словам в Java при каждой конкатенации будет происходить копирование всего блока памяти. В других языках это может происходить только по окончании непрерывного блока памяти, но тоже будет происходить.
И все это не отменяет тот факт, что проблема будет не в самой конкатенации, а в управлении памятью при этом.
Про кривое управление памятью Fesor писал двумя сообщениями выше.
Именно. И он не писал что в Java кривое управление памятью.
У меня сложилось впечатление, что Fesor имеет представление о том как происходит аллокация памяти. Чего не знают обычно пользователи скриптовых и языков с динамической типизацией.
И именно на это он ссылался, что проблема не в конкатенации, а в управлении памятью со стороны разработчика.
php может работать асинхронно, но не out-of-the-box.
И мог это всегда (возможно за исключением версий времен php/fi)
А вот читать файл асинхронно в общем случае не получится ни в пхп, ни в ноде.
Да и не имеет смысла, вы только ухудшите производительность (для HDD) и мало что выиграете для SSD.
Там не было сказано, что в Java кривое управление памятью.
Операции += и .= подразумевают инкрементальное увеличение памяти на каждом шаге, что на этапе когда у вас заканчивается непрерывный блок памяти вызывает проблемы, поэтому их просто не стоит выполнять в циклах с большим числом итераций и/или размерами строк.
В большинстве остальных случаев это не вызывает проблем.
Вопрос корректности фикстур, прогрева кешей и jit-компиляторов открыт, поскольку не читал их методику измерения детально и там есть странные упоминания о запуске через popen(), но… можете ознакомиться самостоятельно
Это в том случае если зависимости типичны для группы action.
Ну так и сделать наследование никто не мешает — некий CommonAction
А если нет?
Не совсем понял, кто и когда в вашем примере делает инъекцию зависимостей в методы action?
Router?
Все это что? Запрос и работу с моделями доктрины?
Если всего много и объекты сложный, то создаётся фабрика.
Или builder для инжекции зависимостей.
А параметры идут уже непосредственно при вызове
Получается именно то самое поведение, которое вам хочется.
PSR-7 middleware фреймворки реализуют именно то, что вы хотите.
Например Zend Expressive
Я говорю о том, как это работает в реальности.
Наступил кому-то на любимую мозоль — получил.
Независимо от степени неадекватности поведения этого самого «кого-то».
Так не бывает.
Минусы в карму это раздражение конкретных пользователей.
И для того чтобы их получить надо нажать на их болевую.
На дурочков нажимать можно слабо, на умных придется надавить сильнее.
Но только вы отстветственны за свою карму — она следствие ваших поступков.
Большие деньги, увы, не могут быть аполитичными.
Чего делают?
Пруф с правильной формулой будет?
Я исходил из следующих моментов
Вывод — ваша статья занимает полчаса рабочего времени, поскольку вы сравнили эти две стоимости.
И, да, даже в доналоговом виде это все равно очень и очень хорошо :)
P.S. Если бы фигурировала фраза «мне проще несколько раз задержаться на полчаса», то все было бы иначе
Вы правы и неправы одновременно.
Правы в том смысле, что можно читать файл и выполнять другие операции параллельно.
Я ваше «синхронно» воспринял как «последовательно».
Все остальное имелось в виду в этом контексте.
Читать файл лучше и быстрее последовательно.
Вопрос после уточнения актуален?
Это может иметь значение в определенных ситуациях.
Формулу стоимости обсуждаемой операции в общем виде можно выразить примерно так
cost = N*CA+BR*CR+BW*CW
где
N — количество вызовов аллокации блока
CA — стоимость аллокации блока.
BR — количество блоков, которые требуется прочитать
CR — стоимость чтения блока.
BW — количество блоков которые требуется записать
CW — стоимость записи блока.
Так вот по вашим словам в Java при каждой конкатенации будет происходить копирование всего блока памяти. В других языках это может происходить только по окончании непрерывного блока памяти, но тоже будет происходить.
И все это не отменяет тот факт, что проблема будет не в самой конкатенации, а в управлении памятью при этом.
Именно. И он не писал что в Java кривое управление памятью.
У меня сложилось впечатление, что Fesor имеет представление о том как происходит аллокация памяти. Чего не знают обычно пользователи скриптовых и языков с динамической типизацией.
И именно на это он ссылался, что проблема не в конкатенации, а в управлении памятью со стороны разработчика.
x/2 > 3000 рублей
В месяц получается больше 1 млн…
И мог это всегда (возможно за исключением версий времен php/fi)
А вот читать файл асинхронно в общем случае не получится ни в пхп, ни в ноде.
Да и не имеет смысла, вы только ухудшите производительность (для HDD) и мало что выиграете для SSD.
Который раз вижу от вас эту фразу.
Хотелось бы услышать конкретику. Что имелось в виду под инфраструктурой?
И usecase где есть существенные отличия.
Если это статьи то ссылки, если это ваш личный опыт, то может быть это отличная тема для статьи на хабре? :)
В отличии от пхп с нодой весьма прохладный опыт работы недошедший до чего-то серьезного
Операции += и .= подразумевают инкрементальное увеличение памяти на каждом шаге, что на этапе когда у вас заканчивается непрерывный блок памяти вызывает проблемы, поэтому их просто не стоит выполнять в циклах с большим числом итераций и/или размерами строк.
В большинстве остальных случаев это не вызывает проблем.
В смысле сильно возрастает время отклика для приложения
У вас там что? Полный офис таких же глупых?
Вопрос корректности фикстур, прогрева кешей и jit-компиляторов открыт, поскольку не читал их методику измерения детально и там есть странные упоминания о запуске через popen(), но…
можете ознакомиться самостоятельно
Чуть выше этот вопрос поднимался разными людьми.
Но дети не хотят по вашему, они хотят лепить…
Поэтому пользуйтесь тем, что вам даёт community.
Ссылка тут неоднократно приводилась.