Comments 65
Может вы бы сразу и пакет собрали под Дебиан?
Для тех кто дружит с английским, советую посмотреть выступление Andrei Alexandrescu: The Hip Hop Virtual Machine.
vimeo.com/68383350
Александреску рассказывает об интересных моментах перехода HipHop на виртуальную машину, и о разных методах оптимизации.
Например, так как у PHP отсутствует строгая типизация, HipHop не может заранее знать какой тип возвратит функция. У этой проблемы нашлось оригинальное решение — HipHop пытается угадать тип по названию функции. Например если функция называется getName, скорее всего возвращается строка.
В видео говорится, что тип успешно угадывается в 99% случаях.
vimeo.com/68383350
Александреску рассказывает об интересных моментах перехода HipHop на виртуальную машину, и о разных методах оптимизации.
Например, так как у PHP отсутствует строгая типизация, HipHop не может заранее знать какой тип возвратит функция. У этой проблемы нашлось оригинальное решение — HipHop пытается угадать тип по названию функции. Например если функция называется getName, скорее всего возвращается строка.
В видео говорится, что тип успешно угадывается в 99% случаях.
o_O какой эпичный костыль.
Если это глупо, но работает, значит — это не глупо. ©
Хотите сказать, работающий говнокод — это не глупо?
В подавляющем большинстве случаев, рабочий говнокод — это профит.
А вот вылизывать неделями код, теряя драгоценное время и деньги — это глупо.
Сам я умом это прекрасно понимаю, а вот на практике не могу переступить через себя. :(
А вот вылизывать неделями код, теряя драгоценное время и деньги — это глупо.
Сам я умом это прекрасно понимаю, а вот на практике не могу переступить через себя. :(
Если «работающий говнокод» решает проблему быстро, сейчас, и в будущем в это место никто лезть не собирается — то оправдание такому подходу еще можно найти.
А если же вы «сейчас» пишете говнокод — который завтра и послезавтра нужно поддерживать и править, то тут уж никакие отговорки, либо «качественно» либо никак.
И еще есть такая умная мысль — Долгоиграющий продукт делать правильно и качественно намного дешевле.
А если же вы «сейчас» пишете говнокод — который завтра и послезавтра нужно поддерживать и править, то тут уж никакие отговорки, либо «качественно» либо никак.
И еще есть такая умная мысль — Долгоиграющий продукт делать правильно и качественно намного дешевле.
Вы абсолютно правы, но лишь при условии что случай идеальный.
Если я буду быдлокодить, абы работало, я запущу 10 проектов. Из 10-ти проектов взлетит один. Потрачу на все это год, но получу взлетевший проект. Дальше я его могу сам или же наняв кого-то, довести до ума или даже переписать с нуля уже нормально. В результате у меня будет взлетевший проект и профит.
Либо, я буду год вылизывать проект, запущу — не стреляет. Следующий — не стреляет. Спустя 10 лет, я делаю тот самый стрельнувший проект, но где мое время?
Ситуация двойственная, дилемма имеет исключения, однако в общем случае с точки зрения выгоды, именно быдлокодить выглядит более разумно.
Если я буду быдлокодить, абы работало, я запущу 10 проектов. Из 10-ти проектов взлетит один. Потрачу на все это год, но получу взлетевший проект. Дальше я его могу сам или же наняв кого-то, довести до ума или даже переписать с нуля уже нормально. В результате у меня будет взлетевший проект и профит.
Либо, я буду год вылизывать проект, запущу — не стреляет. Следующий — не стреляет. Спустя 10 лет, я делаю тот самый стрельнувший проект, но где мое время?
Ситуация двойственная, дилемма имеет исключения, однако в общем случае с точки зрения выгоды, именно быдлокодить выглядит более разумно.
HipHop — не транслятор сферического кода в вакууме.
Он создан для запуска реального, существующего PHP кода, который не был предназначен для скорости.
И если такой костыль работает, то есть сухие цифры показывают что с ним быстрее чем без него, то почему бы его не использовать?
В общем, в Фейсбуке согласны что PHP далеко не идеальный язык, но код уже написан и деваться некуда.
Он создан для запуска реального, существующего PHP кода, который не был предназначен для скорости.
И если такой костыль работает, то есть сухие цифры показывают что с ним быстрее чем без него, то почему бы его не использовать?
В общем, в Фейсбуке согласны что PHP далеко не идеальный язык, но код уже написан и деваться некуда.
Не костыль, а спекуляция для оптимизации. Посмотрите вот на этот слайд. К сожалению, пдф с этой презентацией сходу найти не смог.
А не лучше ли тут использовать phpdoc и его @returns. Странное решение.
Так это нужно для всех функций @returns дописывать.
Цель HipHop запускать PHP, каким бы он ни был.
Цель HipHop запускать PHP, каким бы он ни был.
Человек говорит все же о том, что часто код документирован и довольно глупо не проанализировать аннотации и на их онсове уже гадать.
Да, как написал WaveCut, я имел ввиду, что сейчас уже сложно найти качественный код без аннотаций у каждой функции/поля, либо без возможности вывода типа исходя из кода.
Мне видится очень кривым решение анализировать имена методов. Хотя, если у них там используется вариация польской нотации (sGetName/getNameString, iCount/countStr, ...), то почему бы и нет.
Мне видится очень кривым решение анализировать имена методов. Хотя, если у них там используется вариация польской нотации (sGetName/getNameString, iCount/countStr, ...), то почему бы и нет.
Бессмысленные очевидные комментарии уже являются атрибутом качественного кода.
Куда вы катитесь, хабракомментаторы.
Куда вы катитесь, хабракомментаторы.
Значит, указывать @params, @returns, @throws это уже бессмысленно?
Комментарии пишутся для людей.
Если ваша религия требует заниматься javadoc-извращениями, это не значит что все должны ей следовать.
Например, для getEmailById() состоящей из 2-х строк бессмысленно указывать то, что вы перечислили.
Если ваша религия требует заниматься javadoc-извращениями, это не значит что все должны ей следовать.
Например, для getEmailById() состоящей из 2-х строк бессмысленно указывать то, что вы перечислили.
Комментарии пишутся для людей, если имя метода/функции/etc не дает точного понимания, чего она делает (не обсуждаем сейчас рефакторинг этого случая).
А тот же @ returns часто полезен именно для IDE, если она не может корректно вывести типы.
Аналогично указание @ param поможет IDE ругаться, если в вызов передается не тот тип данных.
А тот же @ returns часто полезен именно для IDE, если она не может корректно вывести типы.
Аналогично указание @ param поможет IDE ругаться, если в вызов передается не тот тип данных.
А Email это строка или объект класса Email? А что будет если функция не найдет емайл? Исключение, null, false? А какого типа параметр нужно передавать? Число, строка, объект? Анотация позволит ответить на все эти вопросы не анализируя код функции, а если он состоит из 2 строк, значит нужно будет лезть вглубь кода и анализировать его.
> А Email это строка или объект класса Email?
> А какого типа параметр нужно передавать?
А зачем это знать?
Пишите код так, чтобы было все равно.
> А что будет если функция не найдет емайл?
Значит она не вернет email.
> Анотация позволит ответить на все эти вопросы не анализируя код функции
А кто сравнивал затраты на написание аннотаций для _всех_ функций в проекте по сравнению с тем, чтобы заглянуть код в редкие моменты, когда нужно такие мелочи прояснять?
> А какого типа параметр нужно передавать?
А зачем это знать?
Пишите код так, чтобы было все равно.
> А что будет если функция не найдет емайл?
Значит она не вернет email.
> Анотация позволит ответить на все эти вопросы не анализируя код функции
А кто сравнивал затраты на написание аннотаций для _всех_ функций в проекте по сравнению с тем, чтобы заглянуть код в редкие моменты, когда нужно такие мелочи прояснять?
Пишите код так, чтобы было все равно.
switch (gettype($email)) {
case 'string':
break;
case 'integer':
$email = new Email($email)->getEmail();
break;
case 'array':
// несколько email передано. где же Composite?
break;
case 'object':
if ($email instanceof Email) {
$email = $email->getEmail();
}
...
}
Ага, пошел переписывать.
Значит она не вернет email.
А что тогда она вернет? Ничего не вернет? А может она бросит исключение?
А кто сравнивал затраты на написание аннотаций для _всех_ функций в проекте по сравнению с тем, чтобы заглянуть код в редкие моменты, когда нужно такие мелочи прояснять?
Вписать в автоматически созданную заготовку phpdoc блока типы значений — дело считанных секунд. А сэкономит это потом и вам и другим разработчикам кучу времени.
Вы писали много кода с использованием сторонних больших библиотек? Особенно используя что-то в первый раз.
>>new Email($email)->getEmail()
не хорошо вышло. но это была передача сути
не хорошо вышло. но это была передача сути
PHP — это язык программирования без строгой типизации.
В нем в большинстве контекстов нет разницы между 1 и «1».
И никто по этому поводу не поднимает бучу, кроме любителей джавы, которые на php пишут как на джаве.
> А что тогда она вернет? Ничего не вернет? А может она бросит исключение?
А что возвращает strpos когда оно ничего не находит? Вы каждый раз в мануал лезете, чтобы это узнать?
Что возвращать, кидать ли исключение — это договоренность, которую можно описать 1 раз вместо того, чтобы как обезьянка копировать во все функциях.
> Вписать в автоматически созданную заготовку phpdoc блока типы значений — дело считанных секунд.
Плюс еще время при каждом изменении функции.
Плюс загромождение кода этим мусором — код распухает.
> А сэкономит это потом и вам и другим разработчикам кучу времени.
Как вы это считали? Мне мой код понятен без комментариев спустя несколько лет.
> Вы писали много кода с использованием сторонних больших библиотек?
Мое впечатление от javadoc «документации» — это формальная отписка, требовалась документация — нате вам документацию.
В нем в большинстве контекстов нет разницы между 1 и «1».
И никто по этому поводу не поднимает бучу, кроме любителей джавы, которые на php пишут как на джаве.
> А что тогда она вернет? Ничего не вернет? А может она бросит исключение?
А что возвращает strpos когда оно ничего не находит? Вы каждый раз в мануал лезете, чтобы это узнать?
Что возвращать, кидать ли исключение — это договоренность, которую можно описать 1 раз вместо того, чтобы как обезьянка копировать во все функциях.
> Вписать в автоматически созданную заготовку phpdoc блока типы значений — дело считанных секунд.
Плюс еще время при каждом изменении функции.
Плюс загромождение кода этим мусором — код распухает.
> А сэкономит это потом и вам и другим разработчикам кучу времени.
Как вы это считали? Мне мой код понятен без комментариев спустя несколько лет.
> Вы писали много кода с использованием сторонних больших библиотек?
Мое впечатление от javadoc «документации» — это формальная отписка, требовалась документация — нате вам документацию.
Вообще, мы уже совсем не о теме поста общаемся. Но все-же отвечу, в последний раз.
Если мы в new Email() передали «1», то что это? Кривой строковый email или числовой id, по которому нужно выбрать данные из БД?
Наверное === и !== придумали и успели добавить в PHP больные психически люди до того, как их поймали и не дали добавить еще и ====.
Возможность вернуть null, false или 0 и всё это различать — это полезный, хоть опасный инструмент.
В C strpos вернет или адрес символа или NULL. Но нам адреса не даны и возможность отличить false от 0 приходится кстати.
А как вы используете язык, если не знаете, как он работает? Переписываете код, пока он не заработает как ожидалось (пройдет тесты, написанные кем-то еще)? Этакий метод Монте-Карло.
А если исключение, то какое именно? Или нужно ловить все Exception, чтобы наверняка? В python вон pycharm вообще по рукам бьет за ловлю главного Exception)
Я чаще вызываю функции/методы, чем переписываю их внешний интерфейс и реализацию :)
Размер — вообще не довод в пропивопославление получаемого удобства. Тем более любой редактор, чуть сложнее cat (утрирую конечно) умеет сворачивать комментарии.
Опыт. Вот, например, если некая общая для нескольких подпроектов библиотечка на 573 метода в куче классов, с группировкой по категориям (namespace или Zend-style не важно). Это лишь небольшая часть всей системы, которая пишется несколькими людьми. И как классно, нажав Ctrl+Q на непонятном/подзабытом методе, увидеть как с ним взаимодействовать как с черной коробкой без необходимости лезть в его реализацию.
Для меня doc-блоки в первую очередь — это помощь при написании кода. Например для той либы на 500+ методов сгенерированной по phpdoc-блокам документации нет. И не нужна она такая. Не затем комментарии пишутся.
Если вы пишете небольшой код для личного использования — ну и ладно. А вот при работе в команде…
Можно вспомнить одну известную фразу:
Давайте закончим это холивар в данном посте, в котором речь о другом совсем. Если хочется продолжить — если личка и нерабочее время.
в большинстве контекстов нет разницы между 1 и «1».
Если мы в new Email() передали «1», то что это? Кривой строковый email или числовой id, по которому нужно выбрать данные из БД?
А что возвращает strpos когда оно ничего не находит?
Возможность вернуть null, false или 0 и всё это различать — это полезный, хоть опасный инструмент.
В C strpos вернет или адрес символа или NULL. Но нам адреса не даны и возможность отличить false от 0 приходится кстати.
Вы каждый раз в мануал лезете, чтобы это узнать?
А как вы используете язык, если не знаете, как он работает? Переписываете код, пока он не заработает как ожидалось (пройдет тесты, написанные кем-то еще)? Этакий метод Монте-Карло.
Что возвращать, кидать ли исключение — это договоренность, которую можно описать 1 раз...
А если исключение, то какое именно? Или нужно ловить все Exception, чтобы наверняка? В python вон pycharm вообще по рукам бьет за ловлю главного Exception)
Плюс еще время при каждом изменении функции.
Плюс загромождение кода этим мусором — код распухает.
Я чаще вызываю функции/методы, чем переписываю их внешний интерфейс и реализацию :)
Размер — вообще не довод в пропивопославление получаемого удобства. Тем более любой редактор, чуть сложнее cat (утрирую конечно) умеет сворачивать комментарии.
Как вы это считали?
Опыт. Вот, например, если некая общая для нескольких подпроектов библиотечка на 573 метода в куче классов, с группировкой по категориям (namespace или Zend-style не важно). Это лишь небольшая часть всей системы, которая пишется несколькими людьми. И как классно, нажав Ctrl+Q на непонятном/подзабытом методе, увидеть как с ним взаимодействовать как с черной коробкой без необходимости лезть в его реализацию.
требовалась документация — нате вам документацию
Для меня doc-блоки в первую очередь — это помощь при написании кода. Например для той либы на 500+ методов сгенерированной по phpdoc-блокам документации нет. И не нужна она такая. Не затем комментарии пишутся.
Если вы пишете небольшой код для личного использования — ну и ладно. А вот при работе в команде…
Можно вспомнить одну известную фразу:
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.
Давайте закончим это холивар в данном посте, в котором речь о другом совсем. Если хочется продолжить — если личка и нерабочее время.
> Вообще, мы уже совсем не о теме поста общаемся. Но все-же отвечу, в последний раз.
Как раз таки по теме поста и общаемся.
Вы предлагаете превратить PHP в строго типизированный язык, вообще отрицая нестрогую типизированность как таковую.
Но можете не отвечать, да, тут и так все понятно.
> Если мы в new Email() передали «1», то что это? Кривой строковый email или числовой id, по которому нужно выбрать данные из БД?
Не знаю, откуда вы вытащили new Email().
Речь шла о getEmailById()
Если вы уж так хотите new Email(), у аргументов есть имена.
$id — это id, $email- это email.
(знаю, сейчас начнется буквоедство. Что такое email можно описать для всего проекта сразу, а не для каждой функции).
> В C strpos вернет или адрес символа или NULL. Но нам адреса не даны и возможность отличить false от 0 приходится кстати.
Спасибо, КО.
Вот примерно тоже самое будет и для getEmailById(). И не надо это к каждой функции в комментарии писать — это задается для всего проекта.
> А как вы используете язык, если не знаете, как он работает?
Обычно в хорошей документации есть общее описание подобных вещей на человеческом языке.
> А если исключение, то какое именно? Или нужно ловить все Exception, чтобы наверняка?
Если непонятно — пишите комментарий // кидает MyException.
Если это очевидно из кода — ничего не пишите.
> Размер — вообще не довод в пропивопославление получаемого удобства.
Нет никакого удобства в тупом описании очевидных вещей по 100 раз.
> Тем более любой редактор, чуть сложнее cat (утрирую конечно) умеет сворачивать комментарии.
Так вот для чего нужны навороченные редакторы :)
Они научились уже автоматом сворачивать ненужные комментарии?
> Опыт
У меня опыт противоположный. Разработчиков api, которыми пользуюсь, иногда прошу меньше внимания уделать документации, потому что там все очевидно.
> Для меня doc-блоки в первую очередь — это помощь при написании кода.
Помощь в написании кода оказывает суть, описанная кратко. И редкие комментарии в неочевидных местах. Написано должно быть людьми для людей.
> Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.
Спасибо, не надо мне давать таких советов. Я — владелец своих проектов. И лучше знаю как расставлять свои приоритеты.
> речь о другом совсем
Речь шла о том, как ускорить PHP.
Люди из Facebook успешно это делают.
Но тут вылезли хабракомментаторы «Вот дураки, нет чтобы PHP превратить в строго типизированный язык».
Как раз таки по теме поста и общаемся.
Вы предлагаете превратить PHP в строго типизированный язык, вообще отрицая нестрогую типизированность как таковую.
Но можете не отвечать, да, тут и так все понятно.
> Если мы в new Email() передали «1», то что это? Кривой строковый email или числовой id, по которому нужно выбрать данные из БД?
Не знаю, откуда вы вытащили new Email().
Речь шла о getEmailById()
Если вы уж так хотите new Email(), у аргументов есть имена.
$id — это id, $email- это email.
(знаю, сейчас начнется буквоедство. Что такое email можно описать для всего проекта сразу, а не для каждой функции).
> В C strpos вернет или адрес символа или NULL. Но нам адреса не даны и возможность отличить false от 0 приходится кстати.
Спасибо, КО.
Вот примерно тоже самое будет и для getEmailById(). И не надо это к каждой функции в комментарии писать — это задается для всего проекта.
> А как вы используете язык, если не знаете, как он работает?
Обычно в хорошей документации есть общее описание подобных вещей на человеческом языке.
> А если исключение, то какое именно? Или нужно ловить все Exception, чтобы наверняка?
Если непонятно — пишите комментарий // кидает MyException.
Если это очевидно из кода — ничего не пишите.
> Размер — вообще не довод в пропивопославление получаемого удобства.
Нет никакого удобства в тупом описании очевидных вещей по 100 раз.
> Тем более любой редактор, чуть сложнее cat (утрирую конечно) умеет сворачивать комментарии.
Так вот для чего нужны навороченные редакторы :)
Они научились уже автоматом сворачивать ненужные комментарии?
> Опыт
У меня опыт противоположный. Разработчиков api, которыми пользуюсь, иногда прошу меньше внимания уделать документации, потому что там все очевидно.
> Для меня doc-блоки в первую очередь — это помощь при написании кода.
Помощь в написании кода оказывает суть, описанная кратко. И редкие комментарии в неочевидных местах. Написано должно быть людьми для людей.
> Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.
Спасибо, не надо мне давать таких советов. Я — владелец своих проектов. И лучше знаю как расставлять свои приоритеты.
> речь о другом совсем
Речь шла о том, как ускорить PHP.
Люди из Facebook успешно это делают.
Но тут вылезли хабракомментаторы «Вот дураки, нет чтобы PHP превратить в строго типизированный язык».
Эх, еще коммент.
Необходимость залезть в функцию и посмотреть ее реализацию — это смена контекста и потеря времени.
Работа с doc-блоками и blackbox методами позволяет держать в голове более высокий уровень абстракции проекта. Более того, держать нужный сейчас уровень, а не (все?) нижележащие.
Про все прочее не хочу отвечать, хоть и есть несколько фраз, которые очень хочется прокомментировать. Вам и так минусуют, может они еще и отпишутся.
Разве что заступлюсь за vim. Вы не поверите, но он умеет сворачивать комменатрии :)
Необходимость залезть в функцию и посмотреть ее реализацию — это смена контекста и потеря времени.
Работа с doc-блоками и blackbox методами позволяет держать в голове более высокий уровень абстракции проекта. Более того, держать нужный сейчас уровень, а не (все?) нижележащие.
Про все прочее не хочу отвечать, хоть и есть несколько фраз, которые очень хочется прокомментировать. Вам и так минусуют, может они еще и отпишутся.
Разве что заступлюсь за vim. Вы не поверите, но он умеет сворачивать комменатрии :)
Да не отвечайте, вы все равно слабо представляете о чем спорите.
Объясню:
Вы устроили холивар на тему «Строгая Типизация» vs «Недоязыки вроде PHP».
Обязательное указание типов параметров, возвращаемых значений — это есть декларация типов. Следующий шаг — проверка этой всей кухни на уровне компилятора, который будет бить по рукам если что не так.
История уже показала, что потребность в языках без строгой типизации — есть. Поэтому спорить тут не о чем.
> Разве что заступлюсь за vim. Вы не поверите, но он умеет сворачивать комменатрии
Ох, правда что ли? :) Спасибо, КО. Я им лет 10 пользовался, как бы в курсе.
P.S.
Самый прикол в том, что хабрахомячки весь этот бред еще и плюсуют.
Объясню:
Вы устроили холивар на тему «Строгая Типизация» vs «Недоязыки вроде PHP».
Обязательное указание типов параметров, возвращаемых значений — это есть декларация типов. Следующий шаг — проверка этой всей кухни на уровне компилятора, который будет бить по рукам если что не так.
История уже показала, что потребность в языках без строгой типизации — есть. Поэтому спорить тут не о чем.
> Разве что заступлюсь за vim. Вы не поверите, но он умеет сворачивать комменатрии
Ох, правда что ли? :) Спасибо, КО. Я им лет 10 пользовался, как бы в курсе.
P.S.
Самый прикол в том, что хабрахомячки весь этот бред еще и плюсуют.
В python вон pycharm вообще по рукам бьет за ловлю главного Exception)Классная фишка, блин!
switch (gettype($email))
самый волнующий момент
«Не назывый функцию getPhone, называй getPhoneNumber — тогда HipHop лучше тип угадает» или «вот тебе таблица английских слов — эти 300 для string, эти 250 для integer и что бы до завтра все выучил» — это трындец… Не проще ли тогда на языке с типизацией писать?
Как по мне, так довольно странное решение. Могли бы возвращать некий object, который внутри содержит знание о том, какого он типа, в том числе базовые строка, число. Когда код написан с правильным предположением о значении — то одна лишняя проверка вообще ничего не стоит, а уж если надо конвертировать, то тут в любом случае проверять придётся. Они же в любом случае должны были делать сборщик мусора, то есть уже нужен какой-то счётчик ссылок или ещё какая-то конструкция. Видимо, это тяжёлое наследие оригинального HipHop.
Вуаля! Получаем все тот же Zend Engine, но сбоку!
Нашёл.
В общем, конечно они держат тип внутри объекта. Но каждый блок кода транслируется в несколько разные бинарные tracelet, как они их называют, которые различаются типами входных объектов. И вот тут как раз работает спекуляция, основанная на имени функции. Можно узнать немножко информации тут: qconsf.com/sf2012/dl/qcon-sanfran-2012/slides/KeithAdams_PHPOnTheMetalWithHHVMMOVEDTOBALLROOMBC.pdf
Есть ещё корявые слайды webcache.googleusercontent.com/search?q=cache:Qpr4ZvKkrWwJ:www.ssrg.nicta.com.au/summer13/Adams.pdf+&cd=2&hl=ru&ct=clnk&gl=ru
В общем, конечно они держат тип внутри объекта. Но каждый блок кода транслируется в несколько разные бинарные tracelet, как они их называют, которые различаются типами входных объектов. И вот тут как раз работает спекуляция, основанная на имени функции. Можно узнать немножко информации тут: qconsf.com/sf2012/dl/qcon-sanfran-2012/slides/KeithAdams_PHPOnTheMetalWithHHVMMOVEDTOBALLROOMBC.pdf
Есть ещё корявые слайды webcache.googleusercontent.com/search?q=cache:Qpr4ZvKkrWwJ:www.ssrg.nicta.com.au/summer13/Adams.pdf+&cd=2&hl=ru&ct=clnk&gl=ru
В PHP всё именно так и происходит. Вероятно хотели что-то другое.
А я вот не очень понял, симфони же можно использовать без аннотаций, конфиги в yaml писать например. Даже framework-standard-edition не запустился?
насколько я понимаю оно не поддерживает неймспейсы.
оО… статический анализатор кода сделать смогли, а простейший механизм неймспейсов — нет… странно.
Получается они на уровне php 5.2… надо бы кохану попробовать запустить
Получается они на уровне php 5.2… надо бы кохану попробовать запустить
github.com/facebook/hiphop-php/issues/716
вот что нашлось
вот что нашлось
Что, серьезно, это тот самый и единственный тест, который вы провели?
Даже как-то не смешно.
<?php
for($i = 0; $i < 1000; $i++) {
echo var_dump($_SERVER);
}
Даже как-то не смешно.
А попробуйте ка в случае с PHP5-FPM+APC выставить apc.stat в «Off».
кто хочет поюзать на Красных Шапках 6 — ставим EPEL и идём качать 198.204.229.178/forgottenbooks.repo
Только что собрал пакет из Hiphop-php транка.
Сервак простоит скорее всего не очень долго, заказчик юзает его для какой-то своей очень временной цели.
В приципе можно wget'ом рекурсивно выкачать контент и поднять у себя (createrepo --update /path/to/RPMS/) -на сейчас там всего чуть более 700Мб.
Да, кстате. Есть поделка от индуса, но в ней столько г… внутри.
Для тех, кто сильно параноидальный может взять SRC RPM, перекачать зановол сорцы и собрать ручками.
Я потратил на секс 14 часов.
Только что собрал пакет из Hiphop-php транка.
Сервак простоит скорее всего не очень долго, заказчик юзает его для какой-то своей очень временной цели.
В приципе можно wget'ом рекурсивно выкачать контент и поднять у себя (createrepo --update /path/to/RPMS/) -на сейчас там всего чуть более 700Мб.
Да, кстате. Есть поделка от индуса, но в ней столько г… внутри.
Для тех, кто сильно параноидальный может взять SRC RPM, перекачать зановол сорцы и собрать ручками.
Я потратил на секс 14 часов.
Для меня самый главный недостаток hiphop — нет поддержки mysqli.
А зачем от тогда нужен, раз на реальных проектах не взлетает? Чисто что бы убедится, что от 0 до 10000 на С считается быстрее? Хотелось бы почитать про удачный опят использования HipHop, если такой у кого-нибудь был.
facebook.com?
Насколько я понимаю, для очень больших проектов имеет смысл писать код под HipHop VM (либо идти на компромиссы, как минимум), т.к. результаты бенчмарка серьезные…
UFO just landed and posted this here
Очень большие проекты часто и написаны чуть ли не в процедурном стиле времен PHP 3 или 4 (впрочем часто они и писались в те времена) и это только ускоряет их (смотрю на некоторые исходники OpenX). И думается мне, что HipHop VM для них как раз таки подойдет в лучшем виде
использовать симфони в проектах с высокой нагрузкой — это уже извращение.
>Requests per second: 40.14 [#/sec] у меня почти в два раза меньше показывает и без HipHop
в целом статья хорошая — спасибо за грабли, хотя у каждого они свои, но всё же — постараюсь не наступать…
давно собирался перевести часть проектов на HPHP
>Requests per second: 40.14 [#/sec] у меня почти в два раза меньше показывает и без HipHop
в целом статья хорошая — спасибо за грабли, хотя у каждого они свои, но всё же — постараюсь не наступать…
давно собирался перевести часть проектов на HPHP
Настораживает
Failed requests: 97
Это при малом времени обработки запросов и больше, чем для классического PHP
Failed requests: 97
Это при малом времени обработки запросов и больше, чем для классического PHP
Меня одного смущает в этом тесте размеры ответов различаются в 2,68 раза?
Фигня какая то по результатам тестов, почему такая большая разница по полученным данным?
Sign up to leave a comment.
HipHop VM: разведка боем под Debian 7 + Nginx + Symfony2