Как стать автором
Обновить
4
0
Дегтярёв Евгений @bat

Go/PHP Developer

Отправить сообщение
Автору следовало бы указать, что это называется Common Table Expressions (CTE) и, очевидно, ничего общего с рекурсивными запросами в Oracle не имеет. Кроме того, CTE используются не только не только для рекурсии.

P.S.
Возможно, следует перенести топик в блог по SQL.
Ага...
как окошки делать научился, как кнопки научился, а как программировать нет...
А в менеджере запланировать?
Индекс по полям, аля пол, и не нужен.
Барнаул, Сибирьтелеком: 64Кб за 500р., 128Кб за 700р, максимум по скорости для физлиц: 512 за 2200р.
Еще три месяца назад и этого не было, было 64 и 128 в три раза дороже.
Нет, интересовались как раз фактом внутренней реализации array_search.
Я обычно нажимаю Win+L :)
наливаю чай и иду на балкон смотреть на реку...
Местами интересно, например, сравнение switch и if/elseif.

а местами абсурдно...

Зачем загонять в массив строки по 10k и потом тестить скорость якобы операций работы с массивами?
"Modify Loop" тому яркий пример: foreach($aHash as $key=>$val) $aHash[$key] .= "a";
Прочитали 10k в переменную, изменили и загнали опять в массив, подозреваю, что основное время уходит на операции с памятью.

У меня на массиве строк из одного символа результаты другие (100к итераций):
0,079с. 202,56% (у автора 544%)
0,158с. 405,13%
0,039с. 100,00%

Странно, что в тесте нет вот этого варианта:
foreach($aHash as &$value) $value = $newValue;
0,023с. 58,97%

А ведь потом будут говорить, что foreach не подходит для изменения массива.


P.S.
Также не понял, зачем сравнивать isset vs empty, если они дают разный результат.
Может дома находятся на границе склейки кадров
Интригующее начало. Спасибо.

P.S.
Опечатка: "Одну из ранних попыток предринял Informix"
> Нда, промашка вышла (( Спасибо что заметили!
Неплохо бы и в статье изменить.
Где-то встречал описание внутренней структуры массивов в PHP, сечас, к сожалению, не могу найти, потому не гарантирую точность. Внутренняя структура массива включает в себя хештаблицу для поиска по ключу, двусвязный список для обхода элементов, плюс служебные поля, например, кол-во элементов, следующий числовой индекс, ссылка на текущий элемент...

В результатах ничего удивительного нет:

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

2. При наличии break - то же самое, что и в первом случае, но на PHP... естественно медленнее.

3. Еще хуже. for/while не лучшее решение для перебора элементов массива, т.к. на каждой итерации выполняется поиск в хештаблице. foreach для этого предпочтительней, ибо просто перебирает элементы списка.
Еще пол года назад для меня было в диковинку открытие в городе подразделения по разработке московской организацией, только разработка, никакой торговли и пр., а сейчас я там работаю.
быстрее some, затем Ctrl+Enter
Да ладно индусы, вчера натравил профайлер на один скрипт, накопал вот такой кусок:

$line = fgets($fp);
$line = preg_replace("/\r*\n/", '', $line);

через который проходит больше 600тыс. строк.
В нске будет труднее конкурировать
вместо
foreach($templateVars as $k=>$v)
$$k = $v;
лучше использовать extract
Случай использования похожих доменов не единичный:
http://www.utro.ru/articles/2008/04/10/729912.shtml

P.S.
Мне понравился метод юниаструм банка
точно, а когда нет света ходит по кабинетам...
А чем тогда будет зарабатывать Zend?

Информация

В рейтинге
5 453-й
Откуда
Алтайский край, Россия
Зарегистрирован
Активность

Специализация

Backend Developer
Senior