Конечно, свободный софт это хорошо, это правильно - по крайней мере намного правильнее пропиетарщины. Вот еще бы не были некоторые проекты на 146% состоящими из индусского кода! Вот взять Вордпресс: популярнейшая платформа, пригодная от бложиков и прочих ГС до приличных порталов. Но вот реализация - это нечто... Который год я борюсь с оной, размер патчсета к полумегабайту приблизился, но практически каждая новая версия доставляет множество новых багофич. Да и просто - доставляет. Версия 3.7, которая и побудила меня к написанию данного пасквиля, отличилась следующим: новая, пустая инсталляция открывает главную страницу... аж 7 секунд!!! Из которых 5 уходит на... проверку наличия обновлений!!! И что самое удивительное, это делается на каждый запрос - в том числе и на всплывающие в IFRAME окошки, и даже на аякс-запросы!
И это - при наличии встроенного планировщика, который вроде как и предназначен для выполнения подобных действий в оффлайне. Да что там планировщик - сделать это в обработке SHUTDOWN, не занимая времени клиента, и не на каждый запрос а максимум раз в сутки!
Вторая поразительная (или паразитственная?) багофича возникла явно давно, но вот поймана была только сейчас: речь о функции wp_check_filetype, которая возвращает MIME-тип по имени файла. Казалось бы, чего тут сложного - выделили расширение файла, и вынули тип из заранее подготовленного массива структуры {расширение} => {тип}.
Но это же Вордпресс! Посмотрите сами на этот шедевЕр:
function wp_check_filetype( $filename, $mimes = null ) { if ( empty($mimes) ) $mimes = get_allowed_mime_types(); $type = false; $ext = false; foreach ( $mimes as $ext_preg => $mime_match ) { $ext_preg = '!\.(' . $ext_preg . ')$!i'; if ( preg_match( $ext_preg, $filename, $ext_matches ) ) { $type = $mime_match; $ext = $ext_matches[1]; break; } } return compact( 'ext', 'type' ); }
Во-первых, сначала надо проверить кому что можно (и естественно вызвать фильтр!), а во-вторых массив подготовлен чуть сложнее - в нем строки вида "'jpg|jpeg|jpe' => 'image/jpeg'", и для поиска по ним нужен цикл, из индекса в котором делается регулярка, и ею проверяется тип файла.
Но самое веселое как всегда в фильтре 
Для многосайтовых инсталляций это функция check_upload_mimes, которая проверяет допустимость конкретного типа для конкретного сайта (получая из опций), делая это двумя вложенными циклами. Казалось бы - ну чего тут такого? Подумаешь, регулярка да отбор... но цимус тут в том, что все это делается для проверки КАЖДОГО файла!!! То есть и получение опций, и обработка двумя вложенными циклами, и прочая прочая. Так что обработка галереи из 400 фотографий заняла аж 10 секунд, из которых 8 - это 400 вызовов этой самой wp_check_filetype.
А ведь достаточно сделать статическую переменную, и при первом обращении сохранить в ней подготовленный массив - и оверхед уменьшится в 400 раз! Аналогично обстоят дела с кучей других функций, которые не принимают параметров, а возвращают практически константу - вычисленное единожды значение. Самый наглядный пример это site_url() и home_url() - да неужто в течение запроса они изменятся?! Однако каждая из них на каждый вызов честно лезет в базу данных, и честно вычисляет УРЛ. Все бы ничего, если б они не вызывались при генерации каждой ссылки на странице - а их порой за сотню. Сотня лишних запросов к БД это само по себе безобразие, но даже если стоит объектный кэш, то общее время выполнения этих двух функций составляет чуть меньше 100мс.
А теперь чуточку арифметики. Пусть на 1 запрос уходит лишняя 0.1 секунды (всего лишь!), при потреблении среднего (сферического в вакууме) ядра проца 25вт лишняя энергия затрачивается 2.5вт*с. Вроде мало. но умножим на 2 000 000 сайтов (именно столько сейчас сайтов на Вордпрессе!), и получим 5000квт*с на 1 запрос, или ~1400квт*ч на запрос. Пусть каждый из этих сайтов имеет посещаемость 100 запросов/день, или 36500 запросов в год - тогда общее лишнее потребление энергии вордпрессом составит... 40 000 МЕГАВАТТ-часов!!! И куда только "зеленые" смотрят
Отзыв:
0 
0
Да весьма интересно... Хоть я например к сожалению не так хорошо знаю компы но общий смысл понятен. Да и интересна сама манера написания статей вызывает уважение и улыбку
Отзыв:
0 
0
Cпасибо за лестную оценку моей графомании, но это как раз тот случай когда нельзя не писАть.
Отзыв:
0 
0
Я не имею привычки льстить в том числе даже начальству от которого много зависит... Такой уж характер. Я просто высказал свое мнение. Просто реально даже прочтение технических статей описаний дает не просто знания а именно позитив и хорошее настроение
Это в отличии от большинства других где просто выложенна куча инфы сухим техническим языком. И вот мало того что при Вашей манере изложения читать намного приятнее так и вдобавок это гораздо лучше запоминается!
А насчет "нельзя не писать" так это точно страна должна знать своих "героев" и простые пользователи должны знать почему их компы иной раз тормозят со страшной силой! Кстати на подобную тему мне где-то в и-нете попадалась статья смысл которой был в том что вроде ненкторые производители "железа" приплачивали программистам для того чтоб они внедряли в проги побольше операций пускай даже бессмысленных требующих побольше быстродействия! И в итоге подобные программы помогали продавать более новое "железо" (соответственно весомо увеличивая прибыли производителя) так-как более слабое работало ну ОЧЕНЬ медленно... Наводит на мысль что это может оказатся нечто подобное.
Отзыв:
0 
0
"Теория заговора" конечно напрашивается, но правда одновременно и печальнее, и смешнее: чтобы сделать хорошо надо стараться, а плохо и само получится. В коммерческом софте качество в первую очередь снижает гонка версий, а свободный вообще свободен от требований качества. Некоторые проекты, как например ядро Линукс, имеют использование в серьезных системах и тщательно "вылизываются" заинтересованными, другие, как например jQuery, изначально разрабатывались с учетом скорости. Большинство же осталось на уровне наколенных поделок младшеклассников, и забито в них не только на скорость, но и на все писаные и неписаные правила.
Пример: движок соцсети BuddyPress содержит компонент Группа, к нему добавлены компоненты Событие и Место. Все они очень похожи - имеют в себе номер, название, описание, список участников и т.д. При соблюдении объектной парадигмы можно было бы иметь тот объект, с которым работаем в настоящее время, в переменной $current_object и обращаться например к номеру как "$id = $current_object->id" независимо от того, с каким объектом сейчас работаем. Вот только все эти мечты разбиваются о маааленькую подлость: номер группы называется group_id, соответственно место и событие - place_id и event_id. В результате обобщенная работа с объектом полностью невозможна, и приходится городить монстров:
if($current_object->type == 'groups')
$id=$current_object->group_id;
else if($current_object->type == 'events')
$id=$current_object->event_id;
else if($current_object->type == 'places')
$id=$current_object->place_id;
Почувствуйте разницу, как говорится! Естественно такие решения скорости не прибавляют, даже доплачивать не приходится
Но основной кошмар начнется, когда появится еще один тип объектов...