Введение

Многие сталкивались с проблемой того, что нужно быстро записать данные на flash-ку, но подлая железяка маленькое устройство ограничивало нас в скорости. Производители конечно не стоят на месте, но, для увеличения скорости, обязательно нужно покупать N-ю, модельку, а старая просто начинает пылиться на полке.
Задумавшись об этом, я начал размышлять: каким же образом можно ускорить запись, не покупая новый девайс. О том что я придумал, и почему у меня ничего не получилось и будет этот пост.

Существует много способов вычисления числа Пи. Самым простым и понятным является численный метод Монте-Карло, суть которого сводится к простейшему перебору точек на площади. Суть расчета заключается в том, что мы берем квадрат со стороной a = 2 R, вписываем в него круг радиусом R. И начинаем наугад ставить точки внутри квадрата. Геометрически, вероятность P₁ того, чтот точка попадет в круг, равна отношению площадей круга и квадрата:
P₁=S_круг / S_{квадрата} = πR² / a ² = πR² / (2 R ) ²= πR² / (2 R) ² = π / 4 (1)
Выглядит это так:

Что такое анализ?
Анализируя алгоритм, можно получить представление о том, сколько времени займет решение данной задачи при помощи данного алгоритма. Одну и ту же задачу можно решить с помощью различных алгоритмов. Анализ алгоритмов дает нам инструмент для выбора алгоритма.
Результат анализа алгоритмов — не формула для точного количества секунд или компьютерных циклов, которые потребует конкретный алгоритм. Нужно понимать, что разница между алгоритмом, который делает N + 5 операций, и тем, который делает N + 250 операций, становится незаметной, как только N становится очень большим.

Зачем определять площадь сложной фигуры?

Да мало ли зачем. Например, возникла необходимость определить площадь территории на карте. Конечно, можно посмотреть в справочнике или поискать в интернете, но иногда и территории бывают нестандартными — допустим, вы озаботились проблемами лесов в пойме Амазонки и хотите ежемесячно измерять площадь зелёных пятен на фотографиях со спутника. Если вы ботаник (в хорошем смысле слова), то вам может понадобиться измерить площадь листовой поверхности разных сортов одного растения. Или, к примеру, более прозаичная задача — нужно зашпатлевать кусок стены, а банки шпатлёвки хватает только на 1 кв. м. — нужно выяснить, покупать одну банку или раскошелиться на две.

При отправке данных на сервер, иногда требуется сохранить информацию введённую пользователем в форму. Это случается, когда добавлению данных помешали ошибки заполнения самой формы и потерять их ой как не хочется. После возврата на страницу формы, требуется восстановить все значения полей и показать ошибки, которые помешали добавлению данных.

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

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

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

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

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

Посмотрел я на днях сказочное видео с выступлением создателя PHP Расмусом Лердорфом на DrupalCon в августе 2008. Расмус рассказывает о тормознутости соременных фреймворов — о причинах и способах ускорить код.

Настолько оно меня торкнуло, что решил я немного отвлечься от функционала и потестировать создаваемую CMS на скорость раньше запланированного. Профайлер не установлен, но все узкие места я и так представлял заранее. Одним из этих узких мест на работающем сайте — была генерация менюшки (многоуровневый массив) с 300 пунктами, разбитых по 20 подменю (у заказчика большая номенклатура, но все хорошо организовано).

Программная реализация была стандартная — через рекурсивные функции — выбираем один уровень из БД, обходим, выбираем подуровень из БД, обходим и т.д. Т.е. на каждую ветку дерева (подменю) — как минимум один запрос. Т.е. у меня было 20 запросов в базу. Не много, но у будущих потенциальных пользователей CMS их может быть еще больше (деревья много где встречаются). А я пользователей люблю и оберегаю. :)