> Никто не запрещает установить qip себе в папку мои документы
каждому?
> Или дать права на запись в програм файлс\квип
Это решает проблему, но не оправдывает разработчиков, которые не знают или игнорируют рекомендации MS. Если такая программа не одна - это превращается это в танцы с бубном.
Во время работы в вузе здорово с этим намаялся. Одной софтине надо в каталог установки писать логи, другой настройки, третей временные файлы, корел какой-то версии вообще создавал временные файлы в корне системного диска, еще какую-нибудь софтину надо первый раз из под админа запускать.
cron тут не причем, PHP сам с определенной частотой запускает сборщик мусора (см. session.gc_probability, session.gc_divisor), возможно, что параметры были выставлены так, что он никогда не запускался.
Если мы говорим о реляционных БД, то первый вариант имеет очень ограниченное применение. Да это универсально, но за универсальность надо платить, в данном случае, производительностью.
Вы можете показать грань между "более-менее последовательный доступ" и "random access"?
Обычный селект:
необходимо вытащить информацию о начислениях/оплатах и пр. по услугам лицевого счета за месяц - 20-100 строк. Данных за месяц 5-6млн. Данные вносятся постепенно в течении месяца.
Где здесь "более-менее последовательный" доступ? Учитывайте, что параллельно выполняется несколько запросов, которые тоже требуют доступа к диску.
Для нивелирования затрат доступа к диску есть решения как уровне железа, так и на уровне ПО СУБД, но если неоптимальное решение генерирует тучу ненужных обращений к данным, то последовательное расположение данных на диске не решит проблему.
Автору следовало бы указать, что это называется Common Table Expressions (CTE) и, очевидно, ничего общего с рекурсивными запросами в Oracle не имеет. Кроме того, CTE используются не только не только для рекурсии.
P.S.
Возможно, следует перенести топик в блог по SQL.
Барнаул, Сибирьтелеком: 64Кб за 500р., 128Кб за 700р, максимум по скорости для физлиц: 512 за 2200р.
Еще три месяца назад и этого не было, было 64 и 128 в три раза дороже.
Местами интересно, например, сравнение 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, если они дают разный результат.
каждому?
> Или дать права на запись в програм файлс\квип
Это решает проблему, но не оправдывает разработчиков, которые не знают или игнорируют рекомендации MS. Если такая программа не одна - это превращается это в танцы с бубном.
Во время работы в вузе здорово с этим намаялся. Одной софтине надо в каталог установки писать логи, другой настройки, третей временные файлы, корел какой-то версии вообще создавал временные файлы в корне системного диска, еще какую-нибудь софтину надо первый раз из под админа запускать.
Я то думаю, почему у меня машина тормозит, когда играю, а это проводник с ума сходит
То же используем.
Обычный селект:
необходимо вытащить информацию о начислениях/оплатах и пр. по услугам лицевого счета за месяц - 20-100 строк. Данных за месяц 5-6млн. Данные вносятся постепенно в течении месяца.
Где здесь "более-менее последовательный" доступ? Учитывайте, что параллельно выполняется несколько запросов, которые тоже требуют доступа к диску.
Для нивелирования затрат доступа к диску есть решения как уровне железа, так и на уровне ПО СУБД, но если неоптимальное решение генерирует тучу ненужных обращений к данным, то последовательное расположение данных на диске не решит проблему.
При выполнении обычного select тоже идет random access к винту и ничего. Это проблема не РСУБД, это проблема отдельного решения.
Вспомнилось
- Ненавижу кошек
- Ты просто не умеешь их готовить.
Как раз наооборот, ибо надо показать откуда ноги растут и в каком направлении копать, в случае углубленного изучения.
P.S.
Возможно, следует перенести топик в блог по SQL.
как окошки делать научился, как кнопки научился, а как программировать нет...
Еще три месяца назад и этого не было, было 64 и 128 в три раза дороже.
наливаю чай и иду на балкон смотреть на реку...
а местами абсурдно...
Зачем загонять в массив строки по 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"