Эта штука вначале пропускает сдвиг для заголовка, потом переходит по нужному смещению (на основе индекса переменной, смещение следующего элемента записано в каждом элементе), а потом вытаскивает нужные данные и десериализует их. Таким образом, для N переменной формата int64 требуется N считываний, а потом распаковка формата (например такого для 2го элемента со значением int(23)):
02 00 00 00 00 00 00 00 // << Это идентификатор
05 00 00 00 00 00 00 00 // << Это размер данных (вроде бы о_0)
( 00 00 00 00 00 00 00
i : 2 3 ; 00 00 00 00 00 00 00 00 00 00 00 // << Это данные
Поэтому использование sysvshm — это самый медленный и неоптимальный способ работы с SystemV, в отличие, например, от всех остальных решений (sysvshm vs. shmop vs. sync vs. ffi), которые предоставляют прямой доступ к памяти как к файлу: https://gist.github.com/SerafimArts/4c8cd05f20384551a65e3a2958557028
P.S. Если же говорить про возможность просто сложить указатель в shmop, то чисто технически это возможно, т.к. и в fcgi и в mod_php память у всех доступна между процессами/потоками (т.е. никакого SIGSEGV и проч. не должно случиться). Т.е. достаточно на посылаемой стороне взять этот указатель, а на получаемой восстановить его в executor_globals. Однако стоит учитывать, что GC на "обеих сторонах" свой собственный, так что в момент refcount = 0 можно словить гонку состояний. Даже если не учитывать то, что любые операции с этим объектом будут подвержены сабжевой ошибке. Да и refcount тоже без атомиков работает вроде как)))
Разница одинарных и двойных кавычек в том, что одинарные принимаются интерпретатором "как есть", а двойные парсятся внутренним компилятором с целью обнаружения в них переменных для подстановки значений.
Не совсем. Выражения:
echo 'Hello World';
// vs
echo "Hello World";
Ну вообще ничем не отличаются и опкод у них полностью идентичный.
Так что про "какие кавчки быстрее" — это миф от людей, которые не смогли вместо php test.php написать php -dopcache.opt_debug_level=0x20000 test.php.
А вот это не совсем так. Если у вас есть в наличии монитор со 120Гц+, то предлагаю найти какую-либо онлайн тестилку по запросу "тест реакции", где раз в определённые промежутки времени по команде следует нажимать на кнопку.
Вы удивитесь, но если потом переключите режим этого же монитора в 60Гц (т.е. чтобы сохранить то же время отклика монитора при иной герцовке) получите падение скорости реакции где-то на 1/3 от эталонного результата.
При этом разница между 200Гц+ и 120Гц тоже есть, но лично я не заметил особо сильной разницы, когда тестировал. Я бы сказал что это погрешности.
Всё равно в конечном виде байтики передаются же. А задача корректно их передать, чтобы на обоих концах все данные были корректно отправлены и корректно приняты. Тоже самое касается задач сериализации/десериализации, задач сохранения в БД и задач корректной и согласованной передачи данных по ABI.
Тогда действительно получается всё вполне себе "законно" и нет никаких проблем с добавлением json5 в качестве замены json, т.к. парсер вполне обратно совместим.
Хм… Сходу могу назвать SQL, где NaN/INF хоть и могут быть, но не являются флоатами/даблами в большинстве реализаций (Ну например MySQL… Ну или PostgreSQL, где это numeric).
Ещё ANSI C (Насколько я нагуглил). Но возможно ошибаюсь, нашёл только для C++.
P.S. Ну я то не спорю, но мне казалось всегда, что это довольно специфичные типы, которые хоть и являются частью системы типов (потомком флоата) большинства языков, но не могут быть представлены однозначной последовательностью битов в двоичном представлении. Ну, типа, как выглядит, например, -INF в LE, чтобы его можно было записать в двоичном виде и потом прочитать на любом языке, получив тот же -INF в качестве значения флоата?
Ну эти ребята мне как-то случайно попались в рекомендациях ютуба. Рекламы вроде никогда не было (по крайней мере не слышал о CSC никогда). Так что оно само как-то "вычленилось из зачисления в инфоциган".
Насколько я знаю (вроде пару лекций слушал/смотрел от них, но это не точно), ещё у JetBrains уровень не ниже CSC.
Я бы их рекомендовал слушать/смотреть/посещать выпускникам профильных специальностей ВУЗов в качестве доп.образования и уже состоявшимся специалистам. "Домохозяйкам" без минимальных знаний алгоритмов, матана хоть какого-то и опыта там делать нечего.
Ну, допустим, Computer Science Center далеко не инфоцигане. У них есть ютуб канал, так что можно ознакомиться с лекциями.
Отдельные, про лямбда исчисления (с небольшим уклоном в хаскель) или про работу с GPU (если не путаю, это вводные по OpenCV), например, вообще отличные.
Поэтому тот же Фабьен, если не путаю, предложил отказаться от аббревиатур в пользу определения "Request-Response Framework" для Симфони. Единственное что остаётся неизменным во всей этой чехорде из роутеров, миддлварей, эвентлистнеров, комманд басов и проч.
Но на счёт теории… Ну вот MVVM из этого списка аббревиатур выделяется очень сильно.
Модель не должна сама с внешним миром коммуницировать. Для этого есть контроллер. поэтому стрелочка от модели должна вести обратно в контроллер, а из контроллера — во вью.
Из контроллера стрелочка только в модель должна вести. А изменения модели должны обновлять вью, связанный с этой моделью.
Если же из контроллера стрелочка ведёт во вью, то это не MVC уже, а MVP (как например в Laravel или Symfony).
Хм… А то что случилось с деливери не показатель? Я, например, как человек, который раньше им пользовался очень "рад" его покупкой яндексом.
Получилась неюзабельная помойка: категорий больше нет, сортировки по времени доставки/рейтингу и проч. нету, чата нет, все промокоды из истории исчезли, да и история тоже, дизайн переделали под ужасный формат Я.Еды, позиций (ресторанов/магазинов) стало на порядки меньше, доставка стала в полтора-два раза дольше. И самое замечательное — убрали чат, оставив только почту и телефон. И если заказ задерживается на час (ну т.е. вместо указанных 20 минут проходит полтора часа), то позвонив по телефону можно услышать замечательное "извините, слишком много обращений, не можем обработать", после чего трубка просто кладётся.
Если говорить про отдел разработки, то половину (утрирую, точных цифр не знаю, но есть знакомые с которыми приключилось) очень крутых и даже известных инженеров просто поувольняли или в другой отдел устроили писать на других языках и работать с другими проектами. Так что не удивительно, что крутой сервис скатился.
Если говорить не про разработку, а другой персонал — работники доставки устраивают массовые забастовки за многочисленные нарушения и незаконные действия со стороны Яндекса. С неделю назад даже вроде уголовное дело завели, за мошенничество или что-то такое (нужно смотреть/гуглить) после встреч с госслужащими, которые решили разобраться в ситуации.
Так что расписывать более детально весь треш и хаос в Я.Еде (+Деливери) и Я.Такси (это из того что знаю) даже не хочется. Это на километр текста ещё выйдет.
Понимаю, что это не весь "Яндекс", но подобное не первый раз же. Просто данный случай самый актуальный на данный момент.
Не факт, всё зависит от контекста. Это разные конструкции и работает код в примере и у вас по-разному. Если мы говорим, например, о Доктрине, то у вас как раз неправильный код.
В данном случае предлагаю поиграться с ReflectionClass::newInstanceWithoutContructor() и найти отличия в поведении у вас в коде и в оригинальном примере ;)
Ну так это обычное "размытие" направлений. За последние пяток лет появились и активно начали влезать всякие Go, Rust, Kotlin (ну ещё есть Elixir как конкурент Ruby, но он не взлетел как-то). Не?
Конечно узнали. Потому что это известный и устоявшийся термин. А попытка перевести терминологию на любой другой язык очень часто приводит к проблемам.
Как минимум потому, что означает он не разработку, а "исследование". Т.е. перевод должен звучать как "потрошение кода", "исследование устройства", "эмуляция поведения", "анализ логики" да вообще что угодно что по смыслу сходит с попыткой понять как писался код, но совсем не соответствует процессу разработки.
А вы хоть раз слышали, чтобы это кем-то хоть раз употреблялось?
Человеку, для того чтобы понять что имеется ввиду, требуется вначале долго вдуплять, потом догадаться перевести на английский и только после этого становится понятным смысл этого словосочетания. Это не "прозрачность", а троллинг читателя/слушателя.
Эта штука вначале пропускает сдвиг для заголовка, потом переходит по нужному смещению (на основе индекса переменной, смещение следующего элемента записано в каждом элементе), а потом вытаскивает нужные данные и десериализует их. Таким образом, для N переменной формата int64 требуется N считываний, а потом распаковка формата (например такого для 2го элемента со значением
int(23)):Поэтому использование sysvshm — это самый медленный и неоптимальный способ работы с SystemV, в отличие, например, от всех остальных решений (sysvshm vs. shmop vs. sync vs. ffi), которые предоставляют прямой доступ к памяти как к файлу: https://gist.github.com/SerafimArts/4c8cd05f20384551a65e3a2958557028
P.S. Если же говорить про возможность просто сложить указатель в shmop, то чисто технически это возможно, т.к. и в fcgi и в mod_php память у всех доступна между процессами/потоками (т.е. никакого SIGSEGV и проч. не должно случиться). Т.е. достаточно на посылаемой стороне взять этот указатель, а на получаемой восстановить его в executor_globals. Однако стоит учитывать, что GC на "обеих сторонах" свой собственный, так что в момент
refcount = 0можно словить гонку состояний. Даже если не учитывать то, что любые операции с этим объектом будут подвержены сабжевой ошибке. Да и refcount тоже без атомиков работает вроде как)))Не совсем. Выражения:
Ну вообще ничем не отличаются и опкод у них полностью идентичный.
Так что про "какие кавчки быстрее" — это миф от людей, которые не смогли вместо
php test.phpнаписатьphp -dopcache.opt_debug_level=0x20000 test.php.А вот это не совсем так. Если у вас есть в наличии монитор со 120Гц+, то предлагаю найти какую-либо онлайн тестилку по запросу "тест реакции", где раз в определённые промежутки времени по команде следует нажимать на кнопку.
Вы удивитесь, но если потом переключите режим этого же монитора в 60Гц (т.е. чтобы сохранить то же время отклика монитора при иной герцовке) получите падение скорости реакции где-то на 1/3 от эталонного результата.
При этом разница между 200Гц+ и 120Гц тоже есть, но лично я не заметил особо сильной разницы, когда тестировал. Я бы сказал что это погрешности.
Т.е. разница в реакции всё же наличествует.
Просто используйте 7-zip, а не winrar.
Всё равно в конечном виде байтики передаются же. А задача корректно их передать, чтобы на обоих концах все данные были корректно отправлены и корректно приняты. Тоже самое касается задач сериализации/десериализации, задач сохранения в БД и задач корректной и согласованной передачи данных по ABI.
Вот я тоже гуглил, но что-то не нашёл.
Тогда действительно получается всё вполне себе "законно" и нет никаких проблем с добавлением json5 в качестве замены json, т.к. парсер вполне обратно совместим.
Хм… Сходу могу назвать SQL, где NaN/INF хоть и могут быть, но не являются флоатами/даблами в большинстве реализаций (Ну например MySQL… Ну или PostgreSQL, где это numeric).
Ещё ANSI C (Насколько я нагуглил). Но возможно ошибаюсь, нашёл только для C++.
P.S. Ну я то не спорю, но мне казалось всегда, что это довольно специфичные типы, которые хоть и являются частью системы типов (потомком флоата) большинства языков, но не могут быть представлены однозначной последовательностью битов в двоичном представлении. Ну, типа, как выглядит, например,
-INFв LE, чтобы его можно было записать в двоичном виде и потом прочитать на любом языке, получив тот же-INFв качестве значения флоата?В json5 спеке есть всякие NaN, +Inf, -Inf, которых может не быть в некоторых языках. Поэтому просто так везде добавить поддержку не получится.
Ну эти ребята мне как-то случайно попались в рекомендациях ютуба. Рекламы вроде никогда не было (по крайней мере не слышал о CSC никогда). Так что оно само как-то "вычленилось из зачисления в инфоциган".
Насколько я знаю (вроде пару лекций слушал/смотрел от них, но это не точно), ещё у JetBrains уровень не ниже CSC.
Я бы их рекомендовал слушать/смотреть/посещать выпускникам профильных специальностей ВУЗов в качестве доп.образования и уже состоявшимся специалистам. "Домохозяйкам" без минимальных знаний алгоритмов, матана хоть какого-то и опыта там делать нечего.
Ну, допустим, Computer Science Center далеко не инфоцигане. У них есть ютуб канал, так что можно ознакомиться с лекциями.
Отдельные, про лямбда исчисления (с небольшим уклоном в хаскель) или про работу с GPU (если не путаю, это вводные по OpenCV), например, вообще отличные.
В рамках терминологии GRASP презентер вполне может быть контроллером)
Поэтому тот же Фабьен, если не путаю, предложил отказаться от аббревиатур в пользу определения "Request-Response Framework" для Симфони. Единственное что остаётся неизменным во всей этой чехорде из роутеров, миддлварей, эвентлистнеров, комманд басов и проч.
Но на счёт теории… Ну вот MVVM из этого списка аббревиатур выделяется очень сильно.
Из контроллера стрелочка только в модель должна вести. А изменения модели должны обновлять вью, связанный с этой моделью.
Если же из контроллера стрелочка ведёт во вью, то это не MVC уже, а MVP (как например в Laravel или Symfony).
Хм… А то что случилось с деливери не показатель? Я, например, как человек, который раньше им пользовался очень "рад" его покупкой яндексом.
Получилась неюзабельная помойка: категорий больше нет, сортировки по времени доставки/рейтингу и проч. нету, чата нет, все промокоды из истории исчезли, да и история тоже, дизайн переделали под ужасный формат Я.Еды, позиций (ресторанов/магазинов) стало на порядки меньше, доставка стала в полтора-два раза дольше. И самое замечательное — убрали чат, оставив только почту и телефон. И если заказ задерживается на час (ну т.е. вместо указанных 20 минут проходит полтора часа), то позвонив по телефону можно услышать замечательное "извините, слишком много обращений, не можем обработать", после чего трубка просто кладётся.
Если говорить про отдел разработки, то половину (утрирую, точных цифр не знаю, но есть знакомые с которыми приключилось) очень крутых и даже известных инженеров просто поувольняли или в другой отдел устроили писать на других языках и работать с другими проектами. Так что не удивительно, что крутой сервис скатился.
Если говорить не про разработку, а другой персонал — работники доставки устраивают массовые забастовки за многочисленные нарушения и незаконные действия со стороны Яндекса. С неделю назад даже вроде уголовное дело завели, за мошенничество или что-то такое (нужно смотреть/гуглить) после встреч с госслужащими, которые решили разобраться в ситуации.
Так что расписывать более детально весь треш и хаос в Я.Еде (+Деливери) и Я.Такси (это из того что знаю) даже не хочется. Это на километр текста ещё выйдет.
Понимаю, что это не весь "Яндекс", но подобное не первый раз же. Просто данный случай самый актуальный на данный момент.
Не факт, всё зависит от контекста. Это разные конструкции и работает код в примере и у вас по-разному. Если мы говорим, например, о Доктрине, то у вас как раз неправильный код.
В данном случае предлагаю поиграться с
ReflectionClass::newInstanceWithoutContructor()и найти отличия в поведении у вас в коде и в оригинальном примере ;)Ну так это обычное "размытие" направлений. За последние пяток лет появились и активно начали влезать всякие Go, Rust, Kotlin (ну ещё есть Elixir как конкурент Ruby, но он не взлетел как-то). Не?
8.0 -> 8.1 самый болезненный переход из-за требований к
ReturnTypeWillChange, так что я бы так оптимистично не был настроен)Конечно узнали. Потому что это известный и устоявшийся термин. А попытка перевести терминологию на любой другой язык очень часто приводит к проблемам.
Как минимум потому, что означает он не разработку, а "исследование". Т.е. перевод должен звучать как "потрошение кода", "исследование устройства", "эмуляция поведения", "анализ логики" да вообще что угодно что по смыслу сходит с попыткой понять как писался код, но совсем не соответствует процессу разработки.
И чем yield from не подходит?
А вы хоть раз слышали, чтобы это кем-то хоть раз употреблялось?
Человеку, для того чтобы понять что имеется ввиду, требуется вначале долго вдуплять, потом догадаться перевести на английский и только после этого становится понятным смысл этого словосочетания. Это не "прозрачность", а троллинг читателя/слушателя.