Блин, вы конечно каждый раз удивляете, я когда начал читать, ждал чего-то вроде «питон был медленным и мы перешли на Java» — но Хаскель, это конечно, неожиданно (мне даже почему-то смешно стало). Вы не боитесь, что вы потом программистов не найдете с такими редкими умениями, если что?
И по поводу пулов
> Мы будем продолжать поддерживать старый пул длительное время
А потом? Вы сами перенесете машины или пользователям придется это делать? Или надо как-то самому все бекапить, создавать новую машину и устанавливать? Непонятно.
Вот вы бы свой Framework и ORM тут описывали и пиарили. Здесь, на Хабре, все же много технически подкованной публики, и им интересны именно технические решения, а не общее описание того, какие вы крутые. Это все так говорят, а в исходный код заглянешь — мама дорогая.
Я не понимаю, откуда у вас берется выгода. В классическом варианте с массивом моделей, допустим, мы делаем 100 раз new Model() и 100 раз setAttributes(). Хорошо. В вашем варианте мы делаем 1 раз new Model(), 100 раз clone Model, 100 раз setAttributes() + выполняется код итератора. Каким образом ваш вариант может быть выгоднее? Я не понимаю.
Действительно, небольшое преимущество есть — clone быстрее new на микросекунду или около того на моем железе. Но это же мелочь. На 20 моделях набежит 20 микросекунд. В то время как доступ через итератор (а не массив) наверняка съест все это преимущество.
Единственное, что я заметил — это то, что если модели не сохранять в массив, то памяти, конечно, расходуется меньше. И все.
И еще выгода может быть, если у вас модель создается долго (в моем примере new Model выполняется 5 мкс). Но это уже вопрос к качеству кода.
Вы проводили тесты? Выгода от создания 1 объекта модели вместо 20 копеечная, так как вы заменили new Model() + setAttributes() на clone + setAttributes() + обвязку итератора. Получается, кода выполняется даже больше. clone точно так же, как и new, выделяет память. Где выигрыш?
Единственный выигрыш, если у вас в модели в конструкторе есть код, и он долго выполняется, clone будет быстрее new. Но если у вас модель долго создается, то это хреновая модель, скажем прямо.
А вообще, в PHP плохо с абстракциями. Я как-то мерял, использование плейсхолдеров в запросе добавляет в среднем 1мс на их подстановку + самая простая модель откушает еще несколько мс. Плюс время на загрузку файлов с классом. Причем это в написанном руками коде, стандартные PHP-ные ORM такой оверхед накидывают, что их вообще лучше не использовать. Дорогие запросы получаются. Если хочется быстро, то конечно, надо использовать PDO::fetch() + массивы, но это ужасно и неудобно. Вот хоть разорвись теперь.
P.S И почему во всех примерах аттрибуты модели хранятся каждый в отдельном свойстве? Тяжелое наследие Явы? Если их хранить в массивчике $attributes, операции fromArray() и toArray() превращаются в 1 строчку кода, и все остальное тоже становится удобнее.
Давайте говорить прямо, на производительность, потребление ресурсов и оптимизацию разработчики Open Source как правило забивают. Достаточно взять любую графическую среду linux например.
Заметьте, в противоположность им, разработчики коммерческих компаний (нормальные разработчики из Гугл/фейсбук, а не индусы-аутсорсеры), наоборот, такими проблемами обеспокоены. Видимо, они более ответственные люди и лучше разбираются в данной области.
Вывод, если вы хотите получить качественный продукт, не пользуйтесь бесплатным ПО! Лучше закажите его разработку у профессиональных разработчиков! (подозреваю, в этом комменте не хватает только номера телефона ответственных разработчиков)
ВАЖНО! Если вы используете трюки типа display: table-cell/table, учтите, что их поддержка весьма кривая, во-первых у вас могут теряться маргины (правильно, какие могут быть маргины у ячеек таблицы), вы-вторых, браузеры автоматом для блока с table-cell могут добавить родительские анонимные блоки table-row и table, и как-то этим сломать верстку.
По мне так, лучший способ — HTML комментарии, так как кроссбраузерно и сразу понятно, зачем они сделаны. Или, если не нужно вертикальное выравнивание, проще использовать флоаты и не париться.
Я же не писал, что плохо использовать разные цвета в интерфейсе. Я вам написал этот комментарий, потому, что вместо того, чтобы в чем-то разобраться, вы тупо копируете куски кода из интернет и ищете ответы на форумах (а надо — в мануалах и исходных кодах). Возможно, какую-то простую программку таким методом и можно написать, но если вы захотите сделать более серьезный проект, или работать в команде, этот подход в итоге провалится. Более того, такой подход, когда человек досконально не разбирается в используемых инструментах, чреват багами.
Но потом я еще подумал, мне кажется, что и с проектированием интерфейсов у вас не очень. Возьмем, например, скриншот таблицы, приведенный в конце статьи. Что мы видим, глядя на него? Бессмысленные иконки в заголовке каждой колонки. Часть иконок не узнаваема, часть непонятно что значит, зачем они поставлены тут, непонятно, видимо по принципу «чтобы были». Стоит ли говорить, что в данном случае вместо пользы (быстрое нахождение нужного элемента) иконки представляют собой визуальный мусор, отвлекающий и замедляющий анализ представленной информации? Возможно, автор не знает, зачем используются иконки и значки в интерфейсах и бездумно повторяет то, что увидел где-то в другом месте?
Кнопки сгруппированы внизу без всякого смысла и логики. Надписи в ячейках прилипают к разделительным линиям без всякого отступа. Сочетания красного и желтого цветов плохо читаемы.
А ведь все эти вещи уже давно изучены и описаны, мне кажется, вам стоило бы почитать не только книжки по Java, но и книжки на тему usability/ux design.
Что касается идеи «визуальной архитектуры» — а давайте, нарисуйте пару концептов, напишите статейку, хабрапользователи, уверен, с удовольствием ее обсудят и укажут вам на все недостатки. Хотя я конечно, сильно сомневаюсь, что описанное вами вообще возможно.
> создание идеальных алгоритмов, вскоре достигнет уровня, когда таки и простая домохозяйка сможет набросать в три клика программку многоуровневого доступа к реляционным базам данных любимого магазинчика, с дисплея холодильника
Не достигнет. Она бросит затею на попытке понять, что такое вообще реляционная база данных (если они все еще будут существовать).
Аргументы добавляются в array-like объект arguments, а локальные переменные — нет. Соотвестственно, на хранение аргументов требуется дополнительная память. Также, в целях оптимизации, движки могут использовать стек для хранения аргументов, что резко ускоряет аварийное завершение скрипта.
Во-первых, ваш пример №1 нечестный, так как там не 52 локальные переменные, а 52 *аргумента* функции. Аргумент ф-и и локальная переменная — разные вещи, согласитесь? Для объективной оценки вы должны вписать var a,b,c… в тело внутренней функции (function recourse), иначе это мы чем-то не тем меряемся.
Потому ваш тест оказался неправильный. Давайте повторим попытку.
Кстати, заодно вы доказали, что использование глубокой рекурсии в JS — крайне глупая вещь. О чем я и написал выше.
> Перечитайте статью. Там написано, что лучше всего это проявляется в рекурсивных функциях.
Эффект от нескольких сэкономленных переменных проявится более-менее заметно, если у вас десятки и сотни тысяч вызовов. Но делать рекурсию такой глубины — крайне глупое, неэффективное и непродуманное решение. У вас оверхед на вход/выход в функцию и расход памяти на стеке перевесит все оптимизации. От такой рекурсии надо избавляться.
Следовательно, эффект от этой оптимизации в общем случае нулевой.
> Суть была в том, чтобы показать, как замыкание меняется функцией без замыкания.
Говоря строго, в JS все функции являются замыканиями, но я понял идею.
> Как по-вашему анимировать элемент, когда по нему происходит просто пробегание курсора, например, как в нижней панели MacOS.
Либо через onmouseover/out на каждом элементе, либо через mousemove на каждом элементе, либо ставить эти обработчики на всю панель сразу — тут надо сравнить, чтобы понять, что лучше. Но точно не снимать\вешать их 100 раз в секунду — вот это действительно бред.
Если вы хотите ограничить частоту вызова, погуглите function throttling — там просто в обработчике события проверяется время последнего вызова, и если прошло меньше N мс, вызов откладывается, но ставить/снимать обработчик в DOM — такое я первый раз вижу. Не говоря, что при этом вы можете потерять событие выхода за пределы элемента например.
Весьма оригинальная вещь, но также весьма бесполезная. Она позволяет транслировать в JS/HTMl только часть кода программы, связанной с обработкой событий оконного интерфейса. Если у вас в проекте эта логика щедро переплетена с работой с файлами, вызовами винапи, собственными компонентами, то вам приличную часть кода придется как-то переписывать.
1) Про память — бред, если вам надо освободить память, напишите n = null; но НЕ ИСПОЛЬЗУЙТЕ одну переменную для разных целей, отлаживать замучаетесь.
2) пример неудачный. Вместо того, чтобы ставить 100/1000 обработчиков onclick, лучше поставить один на родительском элементе.
3) Оптимизация операций — копеечные оптимизации, кстати «Приведение к целому числу» — проще делать через +, например var now = +new Date() (подсмотрел этот код в яндекс-метрике)
4) Проход по массиву. Вместо нечитаемого
> for(var i=arr.length;i--;)
Пишите
> for (var i = 0, l = arr.length; i< l; i++)
выглядит в разы проще и читабельнее, и оптимизация присутствует.
Мысли про медленность обращений к DOM и использование DocumentFragment — здравые. Например, вместо того, чтобы писать $('ul#list li').css({ color: 'red' }) пишите $('ul#list').addClass('withRedChildren') — должно работать быстрее.
Насчет интервала выполнения (разбить длинную задачу на куски и выполнять их каждые 20 мс) — в общем, тоже плохая идея, так как браузер будет все равно тормозить, и пользователь это будет видеть. Лучше упростить код или хотя бы вывести бегунок, что мол, жди, юзер, ничего не поделаешь. Особенно хорошо на скриптах тормозит ИЕ.
Про события перетаскивания — эпический бред. Вы учли, что навеивание/снятие обработчика —это тоже обращение к ДОМу, перестроение внутренних структур данных в браузере, и если вы будет это делать с частотой 100 раз в секунду, это не очень правильно. Гораздо правильнее ждать нажатия кнопки мыши (начало перетаскивания) на нужном объекте, и при нажатии — ставить обработчик onmousemove, при отпускании — снимать.
Троттлить (ограничивать частоту вызова) стоит функцию onresize, так как когда юзер ресайзит окно, пересчитывается и перерисовывается вся страница, и если вы еще будете свои скрипты пересчитыать, это может убить отзывчивость браузера окончательно.
> Как вы знаете, третий аргумент для htmlspecialchars это кодировка. Большинство людей просто упускают этот аргумент, таким образом, получая кодировку по умолчанию. Это значение было ISO-8859-1 до PHP 5.4. Новая версия исправляет это, сделав UTF-8 по умолчанию.
На сайтах с win1251 (я знаю, такие до сих пор есть) символы кириллицы будут поняты как неправильный UTF код и функция видимо будет возвращать пустую строку.
Я лично считаю, что дефолтная кодировка ISO это как раз хорошо, так как с ней функция только меняет 5 символов на сущности, а теперь она будет еще анализировать правильность UTF символов, и работать намного медленнее (и я не представляю ситуации где эта проверка нужна).
И еще, хотелось бы сказать всем, кто кричит о поддержке кодировок — идите на свой Питон, Яву или что у вас там есть. PHP всегда работал с бинарными строками, и работал замечательно, и никакой дополнительной поддержки НЕ требется. Все виду русских и нерусских букв давно поддерживаются. Бинарные строки без кодировок работают быстрее. Используйте utf-8 и mb_* функции для строк, флаг u для регулярок с русскими буквами, и никаких проблем (кроме ф-й из раздела preg-*) у вас никогда не будет. Если же вы настолько тупые, что этого не понимаете, то вам никакая встроенная поддержка юникода уже не поможет. Спасибо.
У button есть еще одна проблема, это vertical-align, который одну и ту же кнопку в разных браузерах выравнивает по-разному. У меня вообще такое ощущение, что в итоге получился неюзабельный тег.
Потому я сам предпочитаю input:submit, завернутый в спан с display:inline-block и кучей ins для декораций.
Да, вы правы, с сарказмом я переборщил. Извиняюсь, что мой комментарий получился слишком язвительным и невежливым. Это, конечно, неправильно.
Тем не менее, подход, с очередью сообщений, мне не нравится, так как он выглядит как неаккуратное решение и провоцирует трудноповторяемые баги (потому, что у тестера или разработчика виджеты могут грузиться в другой последовательности и работать хорошо, а у пользователя — нет). Мне кажется, логичнее дождаться загрузки всех виджетов, а только потом их инициализировать.
Также, несмотря на все красивые слова, на главной mail.ru куча скриптов и стилей просто вставлена в тело страницы, хотя наверняка они для всех пользователей одинаковы.
И по поводу пулов
> Мы будем продолжать поддерживать старый пул длительное время
А потом? Вы сами перенесете машины или пользователям придется это делать? Или надо как-то самому все бекапить, создавать новую машину и устанавливать? Непонятно.
Броузер: Opera 11.11 (хотя я думал, все еще на старой доброй десятке сижу)
При нажатии на табы ничего не происходит. Яваскрипт включен.
Я сделал простейший тест:
paste2.org/p/1898862
Действительно, небольшое преимущество есть — clone быстрее new на микросекунду или около того на моем железе. Но это же мелочь. На 20 моделях набежит 20 микросекунд. В то время как доступ через итератор (а не массив) наверняка съест все это преимущество.
Единственное, что я заметил — это то, что если модели не сохранять в массив, то памяти, конечно, расходуется меньше. И все.
И еще выгода может быть, если у вас модель создается долго (в моем примере new Model выполняется 5 мкс). Но это уже вопрос к качеству кода.
Единственный выигрыш, если у вас в модели в конструкторе есть код, и он долго выполняется, clone будет быстрее new. Но если у вас модель долго создается, то это хреновая модель, скажем прямо.
А вообще, в PHP плохо с абстракциями. Я как-то мерял, использование плейсхолдеров в запросе добавляет в среднем 1мс на их подстановку + самая простая модель откушает еще несколько мс. Плюс время на загрузку файлов с классом. Причем это в написанном руками коде, стандартные PHP-ные ORM такой оверхед накидывают, что их вообще лучше не использовать. Дорогие запросы получаются. Если хочется быстро, то конечно, надо использовать PDO::fetch() + массивы, но это ужасно и неудобно. Вот хоть разорвись теперь.
P.S И почему во всех примерах аттрибуты модели хранятся каждый в отдельном свойстве? Тяжелое наследие Явы? Если их хранить в массивчике $attributes, операции fromArray() и toArray() превращаются в 1 строчку кода, и все остальное тоже становится удобнее.
Плейсхолдеры реализованы из рук вон плохо. Не напишешь вроде:
$dbal->write('INSERT INTO ?table (?#) VALUES (?a)', $table, array( array_key($data), array_values($data) ))
Не говоря о более сложных вещах. Так что все равно надо над ним свою обертку писать. Но в качестве основы годится.
Заметьте, в противоположность им, разработчики коммерческих компаний (нормальные разработчики из Гугл/фейсбук, а не индусы-аутсорсеры), наоборот, такими проблемами обеспокоены. Видимо, они более ответственные люди и лучше разбираются в данной области.
Вывод, если вы хотите получить качественный продукт, не пользуйтесь бесплатным ПО! Лучше закажите его разработку у профессиональных разработчиков! (подозреваю, в этом комменте не хватает только номера телефона ответственных разработчиков)
По мне так, лучший способ — HTML комментарии, так как кроссбраузерно и сразу понятно, зачем они сделаны. Или, если не нужно вертикальное выравнивание, проще использовать флоаты и не париться.
Но потом я еще подумал, мне кажется, что и с проектированием интерфейсов у вас не очень. Возьмем, например, скриншот таблицы, приведенный в конце статьи. Что мы видим, глядя на него? Бессмысленные иконки в заголовке каждой колонки. Часть иконок не узнаваема, часть непонятно что значит, зачем они поставлены тут, непонятно, видимо по принципу «чтобы были». Стоит ли говорить, что в данном случае вместо пользы (быстрое нахождение нужного элемента) иконки представляют собой визуальный мусор, отвлекающий и замедляющий анализ представленной информации? Возможно, автор не знает, зачем используются иконки и значки в интерфейсах и бездумно повторяет то, что увидел где-то в другом месте?
Кнопки сгруппированы внизу без всякого смысла и логики. Надписи в ячейках прилипают к разделительным линиям без всякого отступа. Сочетания красного и желтого цветов плохо читаемы.
А ведь все эти вещи уже давно изучены и описаны, мне кажется, вам стоило бы почитать не только книжки по Java, но и книжки на тему usability/ux design.
Что касается идеи «визуальной архитектуры» — а давайте, нарисуйте пару концептов, напишите статейку, хабрапользователи, уверен, с удовольствием ее обсудят и укажут вам на все недостатки. Хотя я конечно, сильно сомневаюсь, что описанное вами вообще возможно.
> создание идеальных алгоритмов, вскоре достигнет уровня, когда таки и простая домохозяйка сможет набросать в три клика программку многоуровневого доступа к реляционным базам данных любимого магазинчика, с дисплея холодильника
Не достигнет. Она бросит затею на попытке понять, что такое вообще реляционная база данных (если они все еще будут существовать).
Потому ваш тест оказался неправильный. Давайте повторим попытку.
Кстати, заодно вы доказали, что использование глубокой рекурсии в JS — крайне глупая вещь. О чем я и написал выше.
Эффект от нескольких сэкономленных переменных проявится более-менее заметно, если у вас десятки и сотни тысяч вызовов. Но делать рекурсию такой глубины — крайне глупое, неэффективное и непродуманное решение. У вас оверхед на вход/выход в функцию и расход памяти на стеке перевесит все оптимизации. От такой рекурсии надо избавляться.
Следовательно, эффект от этой оптимизации в общем случае нулевой.
> Суть была в том, чтобы показать, как замыкание меняется функцией без замыкания.
Говоря строго, в JS все функции являются замыканиями, но я понял идею.
> Как по-вашему анимировать элемент, когда по нему происходит просто пробегание курсора, например, как в нижней панели MacOS.
Либо через onmouseover/out на каждом элементе, либо через mousemove на каждом элементе, либо ставить эти обработчики на всю панель сразу — тут надо сравнить, чтобы понять, что лучше. Но точно не снимать\вешать их 100 раз в секунду — вот это действительно бред.
Если вы хотите ограничить частоту вызова, погуглите function throttling — там просто в обработчике события проверяется время последнего вызова, и если прошло меньше N мс, вызов откладывается, но ставить/снимать обработчик в DOM — такое я первый раз вижу. Не говоря, что при этом вы можете потерять событие выхода за пределы элемента например.
1) Про память — бред, если вам надо освободить память, напишите n = null; но НЕ ИСПОЛЬЗУЙТЕ одну переменную для разных целей, отлаживать замучаетесь.
2) пример неудачный. Вместо того, чтобы ставить 100/1000 обработчиков onclick, лучше поставить один на родительском элементе.
3) Оптимизация операций — копеечные оптимизации, кстати «Приведение к целому числу» — проще делать через +, например var now = +new Date() (подсмотрел этот код в яндекс-метрике)
4) Проход по массиву. Вместо нечитаемого
> for(var i=arr.length;i--;)
Пишите
> for (var i = 0, l = arr.length; i< l; i++)
выглядит в разы проще и читабельнее, и оптимизация присутствует.
Мысли про медленность обращений к DOM и использование DocumentFragment — здравые. Например, вместо того, чтобы писать $('ul#list li').css({ color: 'red' }) пишите $('ul#list').addClass('withRedChildren') — должно работать быстрее.
Насчет интервала выполнения (разбить длинную задачу на куски и выполнять их каждые 20 мс) — в общем, тоже плохая идея, так как браузер будет все равно тормозить, и пользователь это будет видеть. Лучше упростить код или хотя бы вывести бегунок, что мол, жди, юзер, ничего не поделаешь. Особенно хорошо на скриптах тормозит ИЕ.
Про события перетаскивания — эпический бред. Вы учли, что навеивание/снятие обработчика —это тоже обращение к ДОМу, перестроение внутренних структур данных в браузере, и если вы будет это делать с частотой 100 раз в секунду, это не очень правильно. Гораздо правильнее ждать нажатия кнопки мыши (начало перетаскивания) на нужном объекте, и при нажатии — ставить обработчик onmousemove, при отпускании — снимать.
Троттлить (ограничивать частоту вызова) стоит функцию onresize, так как когда юзер ресайзит окно, пересчитывается и перерисовывается вся страница, и если вы еще будете свои скрипты пересчитыать, это может убить отзывчивость браузера окончательно.
На сайтах с win1251 (я знаю, такие до сих пор есть) символы кириллицы будут поняты как неправильный UTF код и функция видимо будет возвращать пустую строку.
Я лично считаю, что дефолтная кодировка ISO это как раз хорошо, так как с ней функция только меняет 5 символов на сущности, а теперь она будет еще анализировать правильность UTF символов, и работать намного медленнее (и я не представляю ситуации где эта проверка нужна).
И еще, хотелось бы сказать всем, кто кричит о поддержке кодировок — идите на свой Питон, Яву или что у вас там есть. PHP всегда работал с бинарными строками, и работал замечательно, и никакой дополнительной поддержки НЕ требется. Все виду русских и нерусских букв давно поддерживаются. Бинарные строки без кодировок работают быстрее. Используйте utf-8 и mb_* функции для строк, флаг u для регулярок с русскими буквами, и никаких проблем (кроме ф-й из раздела preg-*) у вас никогда не будет. Если же вы настолько тупые, что этого не понимаете, то вам никакая встроенная поддержка юникода уже не поможет. Спасибо.
Потому я сам предпочитаю input:submit, завернутый в спан с display:inline-block и кучей ins для декораций.
Тем не менее, подход, с очередью сообщений, мне не нравится, так как он выглядит как неаккуратное решение и провоцирует трудноповторяемые баги (потому, что у тестера или разработчика виджеты могут грузиться в другой последовательности и работать хорошо, а у пользователя — нет). Мне кажется, логичнее дождаться загрузки всех виджетов, а только потом их инициализировать.
Также, несмотря на все красивые слова, на главной mail.ru куча скриптов и стилей просто вставлена в тело страницы, хотя наверняка они для всех пользователей одинаковы.