Повесьте демона на PHP и торчите сколько хотите :)
Демон хранит необходимые данные у себя. При необходимости — из каждого процесса можно получить значение.
mysql_query(«SELECT * FROM table WHERE id={$_SESSION['id_user']}»);
Внесите эту строку в нормальную IDE с подсветкой или на тот же dumpz — уверяю, будет выглядеть иначе, чем здесь (или на тот же dumpz).
Видимо, никто не читает полностью (не осилили? :)). Я трижды сказал, что вопрос не только в быстродействии, но и восприятии кода
> Ну знаете, можно долго кавычки заменять на одинарные, чтобы конкантенация была быстрее,
Видимо, вы плохо прочли статью либо не осилили ее. Вероятность того, что конкатенация будет быстрее возрастает только с увеличением строки, в которую необходимо подставить переменные. Это же очевидно по двум тестам.
> Ну так вы напишите, что что это копии. Непонятно же… :)
1. Скриншоты профайлера (копии) располагаются…
2. Копии скриншота можно найти тут, тут и тут.
:)
По таблице видно, что 50 запросов — это тысячная секунды — тут я немного потерялся с нулями, аха — согласен.
На тему «Вот в этом как раз есть смысл. :-)», отвечу так: есть смысл в конструкциях типа
$query = sprintf(«SELECT %s FROM `%s` WHERE %s», '`name`,`surname`', DB_PREFIX.self::$db_table, «`id_user`=$id»);
В том же limb есть такое (первое, что встретилось)
$sql = «SELECT {$table}.* FROM {$table}, {$join_table}
WHERE {$table}.». $object->getPrimaryKeyName(). «={$join_table}.$foreign_field AND
{$join_table}.{$field}=». $this->owner->getId(). ' %where%';
Кто-нибудь может объяснить, на кой фиг смешивать 3 стиля подстановки значений в строку? Всему виной либерализм PHP.
Да, игры с временем — весьма относительный (относительно наилучшего метода). Я знаю многих программистов, которые оперируют далеко не базовыми методами оптимизации. Тем не менее, перед релизом подобные вещи подвергаются рефакторингу :)
Не думаю, что они таким образом экономят время. Скорее, делают скрипты более стандартизированными, чтоли ;)
Хех. Голословность? Цифры есть голословность? Вы меня удивили — честно.
Уверяю вас, я не собираюсь оставлять затеи с освещением возможной оптимизации кода на простейшем уровне. :)
Своей очереди ждут тесты схем обработки массивов, тесты производительности 2,3,4-мерных массивов, итераторов, столь популярных в последнее время геттеров/сеттеров (и прочих magic-вещей)…
Да и вопрос, имхо, стоит понимать несколько в другом свете: никто ведь не заставляет писать так, как я говорю: я всего-лишь привожу тесты разных подходов. Каждый вправе сказать «это мелочь» и не использовать — так ведь?
Только вот, в большинстве своем, наиболее шустрые и легкие техники являются стандартными, не допускающими либеральности. Это ли не есть чувство вкуса и красота кода? :)
Ок. Отклонимся от статистики (таки математика элементарная — не всем ясна до конца).
Вся фишка в том, что работа со строками, изначально есть слабое место в PHP — так уж сложилось. В большинстве фреймворков используется генерация запросов к СУБД (в основном, конечно же, MySQL) средствами подстановки в строки значений.
Пример — $q = «SELECT „.$fields.“ FROM {$table} WHERE $conditions». Он является реальным, а не надуманным: использование трех методов генерации строки является, само по себе, противоречащим здравому смыслу.
Еще более веселым является использование генератора запросов а-ля
$result = DB:: query(«SELECT „.$fields.“ FROM %s WHERE $conditions», $table); Я, почему-то уверен, что 50% разработчиков приложений (и доработчиков, в том числе) встречались с такими конструкциями.
Поскольку, создание запросов, само по себе не является одиночной операцией (мне знакомы системы, которые создают по 50 запросов на вывод страницы) и не кешируется, в большинстве своем, то из спичек, собранных на таких мелочах можно построить нечто большее :)
Дело даже не в выигрыше во времени (он действительно будет плюшевым — 5 сотых секунды не играют роли при несущественных нагрузках), но больше в прививании подрастающему поколению «хорошего» стиля кодирования, подразумевающего некий стандарт, который, к тому же, является еще и более верным и логичным ;)
Offtop: три картинки, ибо хостеры изображений часто сносят оные по причине необращения. «На всякий случай».
Vass, идея "игр со шрифтами" впервые была реализована в PHP Defender. Там они игрались с 1,I,l - очень неприятно разбирать такие штуки. И плюсов у дефендера выше - поскольку вариаций из трех символов больше - имена переменных можно делать короче. А про рост производительности с "укорачиваниями" имен переменных можете почитать в сети / поставить сами эксперимент ;)
dalv, отписать-то отписал на мыло. А толку? Тут ведь речь не идет о качестве вашего продукта (каюсь - зря начал разносить скрипт, ибо в сторону начали уходить). Идет речь о концепции продаж и распространения.
Наш скрипт и так самый быстрый из всех при существующем функционале. Но оптимизация хороша в меру, некторые вещи нет смысла убыстрять.
Вот тут вы глубоко заблуждаетесь. Быстродействие вам не помешает только потому, что быстрый код, в основе своей, имеет правильную структуру (за некоторыми исключениями на валидацию - но к вашему продукту это не относится). Имеете правильную архитектуру - имеете расширяемость и правильную логику ;)
ТС: желаете знать, как заставить человека платить? :)
1. Мне недавно постучался человек с интересного форума (nulled.ws) и попросил докрутить к вашей CNCat возможность продавать ссылки в sape. Пару замечаний:
а. Я, как программер, который активно разрабатывает системы OpenSource, так и не смог заставить Вашу систему работать под исконным UTF8, о которой говорилось. Пришлось ставить в cp1251 и в htaccess прописывать Add default charset :)
б. Я, как программер, долго думал как заставить вашу систему выводить код. Нашел как - сделал. Только одно "НО" - почему этого не может сделать рядовой пользователь?
2. Кусок диалога:
Me > Мммм. ломает разбираться. Саппорт не судьба?
Чел < ни. чиловек обращался ани не ответили
Me > все ясно. Сделаем :)
О чем говорит? О том, что человеку не ответили у вас (за что я купил - за то продал).
Да и есть куча причин не продавать "закрытый код", намного весомее приведенных выше. Например? Например, возможность пользователю/клиенту самому дописывать код. Смотреть, как он работает... Править что-то. Разбираться, отправлять баг-репорты (с конкретными "узкими местами"). Такими, как {$_GET=cncatStripslashes((array)$_GET). Вы бы головой подумали, что есть $_GET :).. Если его внутри скрипта не модифицировать - GET так и останется массивом (((array)$_GET)). ПОтери при быстродействии не считали? :) Или, file_exists($CNCAT["system"]["dir_root"].$CNCAT["system"]["dir_config"]."config_ext.php")... Ну да ладно, а то пост в наезды превращается :)
ЗЫ: ничего личного. Но в конктретном скрипте много косяков. На его основе и делаю выводы.
Например, мну нафиг не нужно будет дезендить (nulled.ws), разбирать код руками (обфускация), геморрой с eval (вы бы хоть головой подумали над одной вещью: если чел полезет нуллить скрипт - ему пофиг есть там eval с base_encode или нет :))...
Пока конкретно Вы используете шаблоны на глобальных переменных - вас не спасет никакая обфускация.
Самое главное - открытый код. Открытый "качественный" код. А так да вам в зенде нада его продавать... Дезенд, хотя бы, выравнивает его. Логику "распрямляет" :)
------------
Так вот вам - очевидный плюс закрытого программирования (скрыть свои косяки). И он же- минус. Что делать - выбирать каждому программисту. Опять же, от задачи зависит.
Продаешь штучный продукт - продавай закрытым. Ибо это - штучное. Не найдется одного из 100 клиентов, который за идею OpenSource выступит.
Продаешь открытым - продавай открытым (обычно, с невысокой стоимостью). Но обеспечивай поддержку "на высоте". Я уверен, что еслиб вы отвечали и помогали - человек использовал бы именно вашу копию. А не скачанную с известного ресурса ;)
А xss - это тоже непросто было. Только вот находятся "НЕКТО" кому это очень не нравится (причем, я там понимаю, их ооочень много) и они решают закрыть тему, пропиарив ее на десятках ресурсов.
Только вот головой они не подумали: такие вещи невозможно закрыть на автомате: признаков единых нет. Получается, что они собственноручно подписали приговор SERP по любому запросу (ну посмотрите статистику запросов "xss" в яшке и сравните ее с двухнедельной давностью.)
Сколько нубов теперь полезет гадить в яшку?
Да и не только нубов. Теперь, когда тема полуживая, каждый будет рвать по максимуму (в частности я скормил яшке ссылок на 15.000 уязвимых ресурсов - посмотрите что будет через 2 недели с коммзапросами, когда напарсят бэков на мои сайты. У каждого горе-оптимизатора такая база будет). Мне ведь не место нужно, а траффик. А траффик xss еще дает.
И многие знакомые, которые работали в этой теме сделали точно так же! Так что дружно говорим господину Иванову - Фа... Феньк Ю и идем ждать апов.
То, что поисковикам выгодны дорвеи - ПОЛНЫЙ БРЕД. Основной целью любой пс является предоставление РЕЛЕВАНТНОЙ запросу информации о сайтах.
У ПС одна проблема: я придумал способ поднятия дора, а как закрыть его придумают только через месяц, причем не ПС, а люди...
Так что, господин gulevich, вы очень заблуждаетесь.
Хм... Неплохо так, прочесть серчи и описать все здесь.
Во-первых, господин Иванов загнал данным топиком seo еще дальше. Дело все в том, что Яндекс не перестал индексировать такие страницы, а перестал учитывать (но факт ли?) такие ссылки.
Сейчас я наблюдаю такую картину- на продвигаемые таким способом сайты пошел трафф с "несуществующих страниц". Причем, очень не кислый.
Во-вторых. Оптимизаторы, как ни странно, не нарушают лицензию на поиск, ставя такие ссылки. Нарушают лицензию веб-мастера, которые пишут (используют) кривые движки и не латают их, хотя бы, роботсом или .htaccess. И, если вы думаете, что данная уязвимость (xss, как принято ее называть на SE) - это удел бедных - вы глубоко заблуждаетесь. Примеры сайтов: сайт Большого театра (писался в РБК, кажется), лента.ру и так далее.
В-третьих. По поводу совести. Приведу хорошо всем известную поговорку: Деньги не пахнут.
И, наконец, последнее... Не нужно открывать дырки в Яндексе - этим вы убиваете тему. Специфика работы с Яндексом очень проста, на самом деле: белые методы небюджетного продвижения даааавно не работают. Поэтому рулят темки, которые доступны минимуму людей. Как только о новой технологии становится известно 10 SEO - начинается мусор в выдаче. И далеко не так быстро Яндекс закрывает эти дырки. Поэтому подумайте 100 раз прежде, чем писать подобные вещи.
За сим откланиваюсь. Очень разочаровался в благоразумности людей из столько серьезных организаций.
Демон хранит необходимые данные у себя. При необходимости — из каждого процесса можно получить значение.
Внесите эту строку в нормальную IDE с подсветкой или на тот же dumpz — уверяю, будет выглядеть иначе, чем здесь (или на тот же dumpz).
Я трижды сказал, что вопрос не только в быстродействии, но и восприятии кода
> Ну знаете, можно долго кавычки заменять на одинарные, чтобы конкантенация была быстрее,
Видимо, вы плохо прочли статью либо не осилили ее. Вероятность того, что конкатенация будет быстрее возрастает только с увеличением строки, в которую необходимо подставить переменные. Это же очевидно по двум тестам.
1. Скриншоты профайлера (копии) располагаются…
2. Копии скриншота можно найти тут, тут и тут.
:)
По таблице видно, что 50 запросов — это тысячная секунды — тут я немного потерялся с нулями, аха — согласен.
На тему «Вот в этом как раз есть смысл. :-)», отвечу так: есть смысл в конструкциях типа
$query = sprintf(«SELECT %s FROM `%s` WHERE %s», '`name`,`surname`', DB_PREFIX.self::$db_table, «`id_user`=$id»);
В том же limb есть такое (первое, что встретилось)
$sql = «SELECT {$table}.* FROM {$table}, {$join_table}
WHERE {$table}.». $object->getPrimaryKeyName(). «={$join_table}.$foreign_field AND
{$join_table}.{$field}=». $this->owner->getId(). ' %where%';
Кто-нибудь может объяснить, на кой фиг смешивать 3 стиля подстановки значений в строку? Всему виной либерализм PHP.
Да, игры с временем — весьма относительный (относительно наилучшего метода). Я знаю многих программистов, которые оперируют далеко не базовыми методами оптимизации. Тем не менее, перед релизом подобные вещи подвергаются рефакторингу :)
Не думаю, что они таким образом экономят время. Скорее, делают скрипты более стандартизированными, чтоли ;)
Уверяю вас, я не собираюсь оставлять затеи с освещением возможной оптимизации кода на простейшем уровне. :)
Своей очереди ждут тесты схем обработки массивов, тесты производительности 2,3,4-мерных массивов, итераторов, столь популярных в последнее время геттеров/сеттеров (и прочих magic-вещей)…
Да и вопрос, имхо, стоит понимать несколько в другом свете: никто ведь не заставляет писать так, как я говорю: я всего-лишь привожу тесты разных подходов. Каждый вправе сказать «это мелочь» и не использовать — так ведь?
Только вот, в большинстве своем, наиболее шустрые и легкие техники являются стандартными, не допускающими либеральности. Это ли не есть чувство вкуса и красота кода? :)
Вся фишка в том, что работа со строками, изначально есть слабое место в PHP — так уж сложилось. В большинстве фреймворков используется генерация запросов к СУБД (в основном, конечно же, MySQL) средствами подстановки в строки значений.
Пример — $q = «SELECT „.$fields.“ FROM {$table} WHERE $conditions». Он является реальным, а не надуманным: использование трех методов генерации строки является, само по себе, противоречащим здравому смыслу.
Еще более веселым является использование генератора запросов а-ля
$result = DB:: query(«SELECT „.$fields.“ FROM %s WHERE $conditions», $table); Я, почему-то уверен, что 50% разработчиков приложений (и доработчиков, в том числе) встречались с такими конструкциями.
Поскольку, создание запросов, само по себе не является одиночной операцией (мне знакомы системы, которые создают по 50 запросов на вывод страницы) и не кешируется, в большинстве своем, то из спичек, собранных на таких мелочах можно построить нечто большее :)
Дело даже не в выигрыше во времени (он действительно будет плюшевым — 5 сотых секунды не играют роли при несущественных нагрузках), но больше в прививании подрастающему поколению «хорошего» стиля кодирования, подразумевающего некий стандарт, который, к тому же, является еще и более верным и логичным ;)
Offtop: три картинки, ибо хостеры изображений часто сносят оные по причине необращения. «На всякий случай».
dalv, отписать-то отписал на мыло. А толку? Тут ведь речь не идет о качестве вашего продукта (каюсь - зря начал разносить скрипт, ибо в сторону начали уходить). Идет речь о концепции продаж и распространения.
Вот тут вы глубоко заблуждаетесь. Быстродействие вам не помешает только потому, что быстрый код, в основе своей, имеет правильную структуру (за некоторыми исключениями на валидацию - но к вашему продукту это не относится). Имеете правильную архитектуру - имеете расширяемость и правильную логику ;)
1. Мне недавно постучался человек с интересного форума (nulled.ws) и попросил докрутить к вашей CNCat возможность продавать ссылки в sape. Пару замечаний:
а. Я, как программер, который активно разрабатывает системы OpenSource, так и не смог заставить Вашу систему работать под исконным UTF8, о которой говорилось. Пришлось ставить в cp1251 и в htaccess прописывать Add default charset :)
б. Я, как программер, долго думал как заставить вашу систему выводить код. Нашел как - сделал. Только одно "НО" - почему этого не может сделать рядовой пользователь?
2. Кусок диалога:
Me > Мммм. ломает разбираться. Саппорт не судьба?
Чел < ни. чиловек обращался ани не ответили
Me > все ясно. Сделаем :)
О чем говорит? О том, что человеку не ответили у вас (за что я купил - за то продал).
Да и есть куча причин не продавать "закрытый код", намного весомее приведенных выше. Например? Например, возможность пользователю/клиенту самому дописывать код. Смотреть, как он работает... Править что-то. Разбираться, отправлять баг-репорты (с конкретными "узкими местами"). Такими, как {$_GET=cncatStripslashes((array)$_GET). Вы бы головой подумали, что есть $_GET :).. Если его внутри скрипта не модифицировать - GET так и останется массивом (((array)$_GET)). ПОтери при быстродействии не считали? :) Или, file_exists($CNCAT["system"]["dir_root"].$CNCAT["system"]["dir_config"]."config_ext.php")... Ну да ладно, а то пост в наезды превращается :)
ЗЫ: ничего личного. Но в конктретном скрипте много косяков. На его основе и делаю выводы.
Например, мну нафиг не нужно будет дезендить (nulled.ws), разбирать код руками (обфускация), геморрой с eval (вы бы хоть головой подумали над одной вещью: если чел полезет нуллить скрипт - ему пофиг есть там eval с base_encode или нет :))...
Пока конкретно Вы используете шаблоны на глобальных переменных - вас не спасет никакая обфускация.
Самое главное - открытый код. Открытый "качественный" код. А так да вам в зенде нада его продавать... Дезенд, хотя бы, выравнивает его. Логику "распрямляет" :)
------------
Так вот вам - очевидный плюс закрытого программирования (скрыть свои косяки). И он же- минус. Что делать - выбирать каждому программисту. Опять же, от задачи зависит.
Продаешь штучный продукт - продавай закрытым. Ибо это - штучное. Не найдется одного из 100 клиентов, который за идею OpenSource выступит.
Продаешь открытым - продавай открытым (обычно, с невысокой стоимостью). Но обеспечивай поддержку "на высоте". Я уверен, что еслиб вы отвечали и помогали - человек использовал бы именно вашу копию. А не скачанную с известного ресурса ;)
Только вот головой они не подумали: такие вещи невозможно закрыть на автомате: признаков единых нет. Получается, что они собственноручно подписали приговор SERP по любому запросу (ну посмотрите статистику запросов "xss" в яшке и сравните ее с двухнедельной давностью.)
Сколько нубов теперь полезет гадить в яшку?
Да и не только нубов. Теперь, когда тема полуживая, каждый будет рвать по максимуму (в частности я скормил яшке ссылок на 15.000 уязвимых ресурсов - посмотрите что будет через 2 недели с коммзапросами, когда напарсят бэков на мои сайты. У каждого горе-оптимизатора такая база будет). Мне ведь не место нужно, а траффик. А траффик xss еще дает.
И многие знакомые, которые работали в этой теме сделали точно так же! Так что дружно говорим господину Иванову - Фа... Феньк Ю и идем ждать апов.
У ПС одна проблема: я придумал способ поднятия дора, а как закрыть его придумают только через месяц, причем не ПС, а люди...
Так что, господин gulevich, вы очень заблуждаетесь.
Во-первых, господин Иванов загнал данным топиком seo еще дальше. Дело все в том, что Яндекс не перестал индексировать такие страницы, а перестал учитывать (но факт ли?) такие ссылки.
Сейчас я наблюдаю такую картину- на продвигаемые таким способом сайты пошел трафф с "несуществующих страниц". Причем, очень не кислый.
Во-вторых. Оптимизаторы, как ни странно, не нарушают лицензию на поиск, ставя такие ссылки. Нарушают лицензию веб-мастера, которые пишут (используют) кривые движки и не латают их, хотя бы, роботсом или .htaccess. И, если вы думаете, что данная уязвимость (xss, как принято ее называть на SE) - это удел бедных - вы глубоко заблуждаетесь. Примеры сайтов: сайт Большого театра (писался в РБК, кажется), лента.ру и так далее.
В-третьих. По поводу совести. Приведу хорошо всем известную поговорку: Деньги не пахнут.
И, наконец, последнее... Не нужно открывать дырки в Яндексе - этим вы убиваете тему. Специфика работы с Яндексом очень проста, на самом деле: белые методы небюджетного продвижения даааавно не работают. Поэтому рулят темки, которые доступны минимуму людей. Как только о новой технологии становится известно 10 SEO - начинается мусор в выдаче. И далеко не так быстро Яндекс закрывает эти дырки. Поэтому подумайте 100 раз прежде, чем писать подобные вещи.
За сим откланиваюсь. Очень разочаровался в благоразумности людей из столько серьезных организаций.