Конкретно этот пример про php не совсем корректен, посмотрите на тему php copy on write. Т.е. что для строки 0 байтов, что для строки 1 Мб при таком присвоении не происходит копирования (копирование будет при изменении значения переменной, а так — два имени имеют ссылку на одно значение). Полезная штука кстати — передача здоровенных массивов аргументами функции будет стоить примерно столько же, сколько передача инта, если массивы не меняются.
Если кто-то дочитает :), для таких в танке, как я, кто через пару дней смотрит топики.
Для быстрого чтения можно читать сразу словами, потом группами слов, потом строками, как говорилось выше. Интересное упражнение для этого - попробуйте перевернуть книжку и почитать к верх ногами. Потом обратно, потом опять, и так там по полстраницы-странице. Интересные ощущения. По себе отмечал, что читать реально начинаешь блоками.
Если честно, тема для меня новая, но грамотно писать хочется. На "Вы" всегда заостряется внимание (видимо, большая буква посреди предложения), и как-то слегка некомфортно. С другой стороны - всегда считал это "правильным".
С точки зрения текстов на сайтах всегда это воспринимал, как подчёркивание разницы между "вы" - множественное число, толпа, и "Вы" - конкретный человек, который пришёл и важен. Объясните, где тут подвох? :)
Спасибо, опечатку поправил.
С разными списками - не думаю, что сразу, но сделаю. Пока можно просто в отдельную категорию в конце складывать, чтобы не мешалось, но в целом это в списке доделок, спасибо за пример с Икеей :).
Прошу у всех прощения за досадный баг, очищавший все списки при редактировании одного. Много информации потерялось, очень жаль, что только отследил :(.
Эта штука была написана в последний момент, чтобы иметь возможность в случае чего. Сами понимаете, напишет там кто-нибудь матом, сделает доступным, Яндекс съест, ну кому это нужно?
А так, поскольку сервис в общем-то не публичный, т.е. другому никто никак навредить не сможет, то я сильно сомневаюсь, что оттуда потребуется что-то удалять.
Просто это было основной идеей - что должно быть очень просто. С точки зрения ввода в текстарию здесь помоему исключительно психологический барьер, но вероятно те, кто предпочтёт вводить по одному элементу и вбивать тэги - для этой задачи просто предпочтут обычный листок бумаги, и так будет лучше.
По Java - понятно.
А по тэгам - приведите use-case, как это можно использовать?
Хм, к сожалению такие штуки сложно отлаживать :(, попробую помучать WM2003, есть один в сравнительно близкой доступности, но скорее всего не сразу удастся поправить.
Тогда бы сайт просто не стартовал, но это хорошая идея, я думаю, если будет десяток желающих - надо будет серьёзно задуматься над реализацией такой возможности.
Ну просто я к примеру работаю дома, и браузер открыт 99% времени, печатаю я не десятипальцевой системой, но близко к тому, это на порядок быстрее, чем тыкать в телефон стилусом.
Спасибо :)
По вёрстке - я долго упирался, чтобы сделать без таблиц, потом пришлось забить - конкретная задача проще решалась таблицами, а я в конце концов больше программист, чем верстальщик.
А по логотипу - есть идеи, куда его улучшать? Ну или просто, за что зацепился глаз?
Версия для телефона - пожалуй не самая простая задача, но вполне реализуемая, если это будет востребовано. Кстати, никто не поделится ссылочками на разработку под J2ME, интересуют: удобная среда разработки, примеры. Инет пока на эту тему предметно не исследовал, просто если у кого был опыт, и есть ссылка под рукой - буду признателен.
Я здесь никак не трогаю массивы :), речь идёт о буфере вывода, это несколько другое, это можно понимать как массив конечно, но в терминах Си, т.е. некоторая область памяти. По поводу "оптимизации под обработку текста" - никто не спорит, просто я рассмотрел то, что делает PHP "за сценой", причём не предполагая что-то, а почитав исходники PHP :), это ли не первоисточник, чтобы понять суть?
По оптимизации там кстати много сделано, но скорее в области выделения памяти, в том числе небольших блоков (это обсулавливает ускорение пхп 5.2 по сравнению с предыдущими версиями), суть операции конкатенации от этого не меняется.
Ну и ещё раз, это микрооптимизация, этим можно не заниматься и жить нормально, это так, "хозяйке на заметку" :).
В общем ещё можно задуматься про причины наличия разницы, в мануале чётко сказано про то, что echo результат не возвращает, а print возвращает 1, т.е. print = echo + операция по сохранению результата во временную переменную. Это по определению медленее, но не настолько, чтобы обращать на это внимание :).
Более интересна ситуация с echo $a, $b, $c; VS echo $a . $b . $c. А ещё более интересна ситуация с накоплением вывода в $out путём сотни-другой конкатенаций, а потом вывода. Вот здесь разница будет ощутимой.
Дело в том, что echo $a, $b = поместить в буффер вывода сначала $a, потом $b. Теперь учтём, что буффер для этого предназначен, т.е. в нём память выделяется с запасом, это даст то, что такая операция скорее всего не будет приводить к выделению памяти (вернее будет, но редко, когда буффер переполняется и нужен новый большой кусок памяти).
А вот echo $a . $b = провести конкатенацию строк $a, $b (выделить память, скопировать), потом положить в буффер вывода (который также придётся изменять, если он переполнится, или не придётся, если его хватит). Таким образом имеем всегда дополнительное выделение памяти и дополнительное лишнее копирование.
С конкатенацией ещё забавнее - вариант $out .= $a, и т.п., каждая такая операция - это перевыделение памяти, причём под конец накопления страницы достаточно большого объёма. Это объясняется тем, что в zval'е хранится только указатель на строку + длина, т.е. память выделяется ровно на строку. Вообще в PHP довольно хитрый менеджер памяти (сейчас попробовал вчитаться в исходники, что там). Там для этого случая идёт свой realloc, а он как повезёт, либо просто задействует новый кусок памяти за переменной (если он есть), либо, если его нет - выделяет новый большой и копирует туда.
Подводя итог:
ob_start();
// много раз echo
$result = ob_get_clean();
на большом количестве echo быстрее, чем накопление в $result.
А вот обращать на это внимание или нет - дело каждого. Я просто включил все эти мелочи в свой стиль, т.е. пишу так весь код, приятно знать, что он будет изначально работать чуть быстрее. Хотя вылизыванием старого кода так заниматься не стоит - есть куда более действенные способы оптимизации. А так - если есть два варианта сделать одно и то же, и они одинаковы по сложности реализации, то почему не выбрать тот, что работает быстрее? :)
Ну к примеру мы считаем статистику, статистика вставляется с ключём "дата", "элемент", статистика за определённый период может пересчитываться (с целью корректировки, скажем, или просто что-то падало и надо восстановить). Соответственно идёт дубликат по первичному ключу, самое простое - REPLACE и не париться. Однако, если в обновлённой статистике элементов стало меньше - то в том, что посчитается будет смесь правильных данных и того, что было. Выход - сначала удалить период за дату, потом вставить - будут чистые данные. Казалось бы, дурацкая ошибка, но я с таким сталкивался.
На мой взгляд INSERT IGNORE, также, как REPLACE и ON DUPLICATE KEY UPDATE - порой очень опасные конструкции, т.е. их если применять, то в очень узких местах, когда действительно, лишний запрос недопустим, и полностью осознавая, что делаешь.
За свою практику встречал случаи, когда люди этими конструкциями "затыкали" ошибки в запросах, что приводило потом к очень долгой и проблематичной отладке (т.к. заткнули симптомы, а причина осталась и потом вылезает в самых неожиданных местах).
Действительно, было бы очень интересно посмотреть на исходники этого дела. Сам недавно задумывался над разработкой CMS именно по такому принципу, пользователю - редактирование, программистам - настройка всего остального. Можно было бы скооперироваться, т.е. если оно станет опен-сорсом и вполне подходящим для использования - дописывать вместе с комьюнити, при этом никто не мешает получать деньги с разработки конкретных экземпляров сайтов (насколько я понимаю, та же GPL это вполне допускает).
Кстати, подскажите, у вас на скриншотах редактирование хтмл-я с подсветкой синтаксиса, чем такое делается?
Для быстрого чтения можно читать сразу словами, потом группами слов, потом строками, как говорилось выше. Интересное упражнение для этого - попробуйте перевернуть книжку и почитать к верх ногами. Потом обратно, потом опять, и так там по полстраницы-странице. Интересные ощущения. По себе отмечал, что читать реально начинаешь блоками.
С точки зрения текстов на сайтах всегда это воспринимал, как подчёркивание разницы между "вы" - множественное число, толпа, и "Вы" - конкретный человек, который пришёл и важен. Объясните, где тут подвох? :)
С разными списками - не думаю, что сразу, но сделаю. Пока можно просто в отдельную категорию в конце складывать, чтобы не мешалось, но в целом это в списке доделок, спасибо за пример с Икеей :).
Правда с тэгами всё равно не понял, куда их? Как категоризация бооольшого списка товаров?
А так, поскольку сервис в общем-то не публичный, т.е. другому никто никак навредить не сможет, то я сильно сомневаюсь, что оттуда потребуется что-то удалять.
По Java - понятно.
А по тэгам - приведите use-case, как это можно использовать?
По вёрстке - я долго упирался, чтобы сделать без таблиц, потом пришлось забить - конкретная задача проще решалась таблицами, а я в конце концов больше программист, чем верстальщик.
А по логотипу - есть идеи, куда его улучшать? Ну или просто, за что зацепился глаз?
Версия для телефона - пожалуй не самая простая задача, но вполне реализуемая, если это будет востребовано. Кстати, никто не поделится ссылочками на разработку под J2ME, интересуют: удобная среда разработки, примеры. Инет пока на эту тему предметно не исследовал, просто если у кого был опыт, и есть ссылка под рукой - буду признателен.
По оптимизации там кстати много сделано, но скорее в области выделения памяти, в том числе небольших блоков (это обсулавливает ускорение пхп 5.2 по сравнению с предыдущими версиями), суть операции конкатенации от этого не меняется.
Ну и ещё раз, это микрооптимизация, этим можно не заниматься и жить нормально, это так, "хозяйке на заметку" :).
Более интересна ситуация с echo $a, $b, $c; VS echo $a . $b . $c. А ещё более интересна ситуация с накоплением вывода в $out путём сотни-другой конкатенаций, а потом вывода. Вот здесь разница будет ощутимой.
Дело в том, что echo $a, $b = поместить в буффер вывода сначала $a, потом $b. Теперь учтём, что буффер для этого предназначен, т.е. в нём память выделяется с запасом, это даст то, что такая операция скорее всего не будет приводить к выделению памяти (вернее будет, но редко, когда буффер переполняется и нужен новый большой кусок памяти).
А вот echo $a . $b = провести конкатенацию строк $a, $b (выделить память, скопировать), потом положить в буффер вывода (который также придётся изменять, если он переполнится, или не придётся, если его хватит). Таким образом имеем всегда дополнительное выделение памяти и дополнительное лишнее копирование.
С конкатенацией ещё забавнее - вариант $out .= $a, и т.п., каждая такая операция - это перевыделение памяти, причём под конец накопления страницы достаточно большого объёма. Это объясняется тем, что в zval'е хранится только указатель на строку + длина, т.е. память выделяется ровно на строку. Вообще в PHP довольно хитрый менеджер памяти (сейчас попробовал вчитаться в исходники, что там). Там для этого случая идёт свой realloc, а он как повезёт, либо просто задействует новый кусок памяти за переменной (если он есть), либо, если его нет - выделяет новый большой и копирует туда.
Подводя итог:
ob_start();
// много раз echo
$result = ob_get_clean();
на большом количестве echo быстрее, чем накопление в $result.
А вот обращать на это внимание или нет - дело каждого. Я просто включил все эти мелочи в свой стиль, т.е. пишу так весь код, приятно знать, что он будет изначально работать чуть быстрее. Хотя вылизыванием старого кода так заниматься не стоит - есть куда более действенные способы оптимизации. А так - если есть два варианта сделать одно и то же, и они одинаковы по сложности реализации, то почему не выбрать тот, что работает быстрее? :)
За свою практику встречал случаи, когда люди этими конструкциями "затыкали" ошибки в запросах, что приводило потом к очень долгой и проблематичной отладке (т.к. заткнули симптомы, а причина осталась и потом вылезает в самых неожиданных местах).
Кстати, подскажите, у вас на скриншотах редактирование хтмл-я с подсветкой синтаксиса, чем такое делается?