После того, как фрактал в примере получился ну архи ме-е-е-е-е-дленным, решил немного исправить ситуацию. Все дело в том, что данную программку я написал как демо для объекта z.Canvas из z.Tools а z.Canvas - это на самом деле хелпер, который рисует графические примитивы при при помощи SVG и VML в зависимости от того, что доступно в текущем браезере. Идея была сделать именно холст, на котором можно было бы рисовать и в Internet Explorer и во всех остальных браузерах, ведь IE, как известно, до девятой версии не поддерживает SVG. Как следствие, каждый примитив на этом "холсте" будет занимать память, и если нарисовать фрактал из прямоугольников на холсте 300 на 300 пикселей, то компьютеру придется выделить память для девяносто тысяч маленьких объектов, само по себе это не сильно много, но всё равно, значительно тормозит весь процесс.

Переделать это дело на "настоящий" HTML5 canvas было делом нескольких минут, вот она, версия на Canvas, работает значительно быстрее и уже не жрет большого количества памяти.

Уже выложив, придумал, как ещё немного ускорить процесс рисования - сейчас, каждая точка рисуется в отдельном потоке через setTimeOut а это тоже страшно медленно - если делать без setTimeout процесс "подвиснет" пока не завершится рассчет фрактала, но можно сделать, чтобы рисовалась не точка но целая линия - это ускорит весь процесс без "зависания" процесса рисования.

Пользуясь небольшим перерывом в эти новогодние каникулы сделал небольшую программку, рисующую жопу множество Мандельброта. Работает, к сожалению, медленнее чем версия на С++, зато картинка получается отменной.

Понадобилось посчитать дистанцию между двумя точками заданными в GPS координатах. В PHP реализация такой фунции выглядит следующим образом:

function calcMiles ($Lat1, $Lon1, $Lat2, $Lon2){
    return 3958.75 * acos(  sin($Lat1/57.2958) * sin($Lat2/57.2958) + cos($Lat1/57.2958) * cos($Lat2/57.2958) * cos($Lon2/57.2958 - $Lon1/57.2958));
}

Ответ получается в милях, для перевода в метры, полученное значение нужно ещё умножить на 1609.344.

Код взял с phpclasses.com. Кстати, глядя на код оригинального класса можно сделать вывод, что автор обладает хорошим чувством юмора - он реализовал вывод результата в десятках различных единиц, включая нанометры, парсеки и световые года.

Выходные провёл с пользой - сделал ещё один простейший текстовый редактор, на этот раз под Андроид. Конечно, уже существует огромное множество готовых редакторов, но мне захотелось создать свой, ведь лучший способ научиться что-либо делать — делать самому. Собственно, идея сделать текстовый редактор появилась после того как я снёс с телефона Ted - работает весьма странно, иногда ни с того ни с сего портит кодировку файла а при сохранении постоянно спрашивает имя сохраняемого файла - это меня сильно достало, ведь сохраняюсь я постоянно, хотя, в целом ted — не плохой редактор.

Вообще, у меня полно задумок относительно того, что можно создать на этой платформе, вот, первый блин уже появился, надеюсь, что появятся и другие.

Большое спасибо Александру Понамарёву за классный диалог выбора файлов, без него у меня бы ушло гораздо больше времени.

Ссылка на apk файл.

Я уже писал, что нужно сделать, чтобы заменить в коде Posix регулярные выражения, которые в PHP 5.3 стали deprecated, на Perl совместимые. Оказывается Rerl совместимые регулярные выражения поддерживают литералы используемые в Posix такие как [[:allnum:]], [[:space:]] и т.д. В одном месте чужёго кода заметил это, и вот дошли руки проверить на практике: конструкция вида preg_match('/[[:space:]]/','df d') работает идентично конструкции вида preg_match('/\s/','df d') т.е. совсем не нужно при замене ereg на preg_match заменять еще и литералы, достаточно добавить слева и справа слеши "/". Кстати кроме слешей можно использовать любой другой символ, например "#" это полезно когда в регулярном выражении уже есть слеши - чтобы их не экранировать и не ухудшать читаемость кода.

Вызов статических методов классов — прекрасная альтернатива обычным функциям - и класс создавать не нужно и принципы объектно-ориентированного программирования не нарушаются. Однако, в реализации статических методов в PHP  есть несколько проблем - статические методы не всегда корректно наследуются, поэтому, чтобы нивелировать неудобства статических методов в PHP часто используют синглетоны - обертывают денимические методы статическими обертками.

Однако, создание синглетона операция довольно ресурсоёмкая — проверить создан ли экземпляр класса, создать экземпляр класса если он не создан, вызвать на нём нужный метод. Насколько это сказывается на бытродействии я и решил сегодня проверить.

Для оценки скорости доступа к методам синглетона я сделал небольшой скрипт. Скрипт генерирует тестовые последовательности вызовов функций в различных вариантах - и сравнивает время вызовов этих последовательностей.

Вот исходный код скрипта.

Результат работы скрипта представлен в таблице ниже:

В тестовом скрипте, я сравнил обычные PHP функции, статические методы класса, обычные методы и методы синглетона.

Результаты тестирования показали, что вызов методов синглетона, примерно в два - четыре раза медленнее, чем вызов обычных методов, что, в принципе, меня порадовало — я ожидал, что будет хуже.

При этом выяснилось несколько дополнительных вещей: cтатические вызовы функций объявленных без модификатора "static" примерно в два раза медленнее, чем с ним, cтатические методы немного медленнее, чем динамические.

Так что, в принципе, синглетоны вполне можно использовать, особенно в случаях, когда быстродействие не сильно критично.

Не знаю, сталкивался ли кто или это мне повезло, но вчера поймал загадочный баг, похоже, что в движке PHP, хотя, пока до конца не уверен.

Предыстория такая - работаю над проектом, над которым потрудились индийские программисты. Сам проект сделан на движке Symphony - добротный такой движок, вполне приятный. В качестве библиотеки работы с базой данных используется Creole - тоже довольно приятная штука. В качестве ORM используется Propel — штука громоздкая, но тем не менее тоже весьма мощная и простая. Вообще Symphony показался мне весьма неплохим движком, весьма простым и удобным. Наверно, потому, что он почти один в один копирует Ruby on Rails - те же хелперы, тот же yml в конфигах, такой же подход к MVC - в общем очень похоже.

Так вот, доблестные индийские программисты, вместо того, чтобы использовать оснастку из Symphony навставляли везде mysql_connect и mysql_query. И все бы ничего, но mysql_connect у них вставляется ВЕЗДЕ перед mysql_query — в одном скрипте может быть создано несколько десятков соединений, а каждый mysql_query дополняется проверкой "or die(mysql_error())", поэтому любая ошибка в sql ведет к скоропостижной кончине всего скрипта.

Чтобы хоть как то исправить это безобразие я сначала удалил все mysql_connect. Затем, все mysql_query поиском и заменой заменил на собственную функцию, использующую оснастку creole, поместил её в глобально видимый класс myTools::query():

static function query($sql){
         $connection = Propel::getConnection();
         $r = $connection->executeQuery($sql);
         return $r->getResource();
}

Странное дело код ведь тривиальный, но ресурс возвращаемый этой функцией оказался невалидным! Причем внутри функции ресурс еще остаётся рабочим а возвращённый во вне оказывается сломанным. Тот же код ВНЕ функции идеально работает, но как только выношу его в функцию — перестаёт работать.

Что это — глюк самого PHP или глюк Simphony я так и не понял, пришлось немного модифицировать класс MySQLConnection и добавить туда метод возвращающий MySQL ресурс непосредственно, минуя всякие PHP обёртки, но осадочек все же остался...

Не спорю, штука прикольная, но уж больно архитектура у него специфическая:

1. нет OOP: несмотря на то, что в системе вроде бы присутствуют классы - основная функциональнасть реализована на функциях;
2. плохие привычки программирования: широко используются глобальные переменные;
3. JavaScript ад: бардак со скриптами - доходит до того что каждый плагин тянет за собой собственный jquery или prototype;
4. тем полно, но все кривые: темы сделаны по-идиотски - нет единого соглашения для создания тем, нет четкого разделения навигации и шаблонов - по сути вся навигация и функционал заложены в теме - а это половина движка;
5. нет MVC: собственно нет шаблонов вообще - логика перемешана с HTML так не кодируют уже давно;
6. SQL: движёк для работы с базой данных неплох - но он негибкий, заточен только под WP и только под MySQL;
7. CMS: виджеты можно настраивать для всех страниц сразу, выборочно никак нельзя;
8. низкое быстродействие: из-за навороченной системы фильтров и хуков в финале система получается тормозная и прожорливая;
9. разработчики не подозревали о существовании других временных зонах кроме UTC: в коде жёстко прописано date_default_timezone_set('UTC');

Изучаю RoR, в принципе нравится. Многие вещи сделаны классно но некоторые вещи вызвали у меня недоуменье:

- обязательный REST: контроллеры генерят код для HTML и для XML хотя их никто об этом не просит. Возможно это круто и обосновано, однако это приводит к избыточности в коде, и созданию функциональности, которая никогда не будет востреботвана.

- обязятельный JavaScript:удаление элементов происходим методом DELETE, хотя браузеры обычно этот метод не используют, поэтому, для вызова DELETE методов используется объект HttpRequest. Как следствие, в браузере обязательно должен быть включен JavaScript. Если JavaScript выключить стандарные методы удаления объектов перестают работать. Это - не гуд.

- избыточность в структуре проекта: методы генерации объектов создают сразу код на все случаи жизни... И что мне после этого удалять вновь созданные файлы если что то не нужно?

Сессии в PHP - вещь замечательная, она позволяет ускорить многие вещи на сайте, например, при выполнении долгих запросов к базе данных их можно записать в сессию и затем полученные значения сохранять в сессию и использовать по мере необходимости, однако, у сессий есть одно свойство, которое может гарантированно свести на нет все попытки увеличить быстродействие вашего сайта. Дело в том, что сессии в PHP блокируют ВСЕ страницы загружаемые для текущего пользователя до тех пор, пока страница, которая перавая успела заблокировть сессию не будет выгружена из памяти сервера. Т.е. если имеем одну медленную страницу с открытой сессией, которая выполняется, скажем, десять секунд - то в течении этих десяти секунд ВСЕ параллельно загружаемые странички будут блокированы и будут ждать пока медленная страница не будет сгенерирована до конца и выгружена и памяти.

В качестве примера, создадим две странички:

slow.php

<?php
print 'START....';

sleep(10);

print 'DONE';

fast.php:

<?php

print 'START....';
print 'DONE';
 

как видим обе странички работают вместе просто прекрасно, пока одна страничка генерируется десять секунд вторая загружается почти мгновенно, теперь добавим в обе страницы работу с сессиям:

slow.php

<?php
session_start();
print 'START....';

if (!isset($_SESSION['counter'])){
    $_SESSION['counter'] = 0;
}
else {
    $_SESSION['counter']++;
}
sleep(10);

print 'DONE';

fast.php:

<?php
session_start();
print 'START....';

print isset($_SESSION['counter'])?$_SESSION['counter']:'none';

print 'DONE';
 

Все попались, теперь, пока медленная страничка не завершиться, быстрая страничка будет ее ждать, т.к. файл с сессией остался заблокирован медленной страницей.

Одним из вариантов для решения подобной проблемы можно вызвать session_write_close(); перед заведомо медленной процедурой. В этом случае сессия будет закрыта досрочно и блокировка с файла будет снята, правда изменять какие либо значения в сессионных переменных уже не получится.

Финальный вариант slow.php:

<?php
session_start();
print 'START....';

if (!isset($_SESSION['counter'])){
    $_SESSION['counter'] = 0;
}
else {
    $_SESSION['counter']++;
}

session_write_close();
sleep(10);

print 'DONE';

В большинстве случаев это должно помочь. К счастью, каждый пользователь имеет собственную сессию и других пользователей медленная страница блокировать не будет. Но все равно, при работе с сессиям нужно учитывать возможности блокировки и по возможности их избегать.

Upd: Кроме этого, если после долгой операции нужно еще что нибудь поменять можно перед долгой операцией сначала закрыть сессию при помощи session_write_close() а потом её снова открыть при помощи session_start(). Однако, делать это можно только если вы ничего ещё не начали выводить в поток, иначе будет известный Warning: Headers already sent....