Немного медленнее грузится винда, после загрузки несколько-минутный тупняк которого еще вчера небыло. Вчера ничего не ставил из софта и кроме новой серии Top Gear ничего не качал. Вирусов не ловил года 4, новых процессов не добавилось, подозрительных файлов тоже, Nod32 молчит. Sata контроллер работает в режиме AHCI, дополнительный контроллер отключен за ненадобностью, системный винт подключен к порту 1, остальные 2 в портах 5 и 6.
Меня тоже интересует как это проверить. Похоже у меня начали появляться проблемы, причем уже на 5ый день после покупки, а именно сегодня сутра. Мать MSI P67A-GD65.
Спасибо, прям от души отлягло. Ай нет, не отлягло, IDE ж ушел на покой, поэтому при наличии DVD/BluRay остаётся только один диск.
P.S. А что делать тем у кого 3 диска и DVD/BluRay?
P.P.S. А если через год место закончится и захочется поставить свеженький 4Tb диск? отказаться от DVD/BluRay? Не выход
Как это разработчик Heroes (пусть даже Kingdoms) не знает кто делал первые 4 части, называет Heroes VI — FPS и сравнивает её со Старкрафтом. Кстати он не в курсе что IV-ую часть делал совсем не Ubisoft и именно из-за того что она считалась неудачной 3DO обанкротилась (в 2003м, а не в 90-ых) после чего серия была куплена Ubisoft. Бррррр…
Вариант со скобочками предпочтительнее, т.к. он лучше читается и он надежнее, можно не думать правильно ли интерпретатор распарсит переменную в строке.
У нас в проекте несколько таблиц милионников размерами от сотен до гигабайт, запросы больше 0.2с редкость, да и те в моменты пиковой нагрузки. Индексы решают, главное правильно ими пользоваться, только расстановки индексов не всегда достаточно, частенько надо немного поправить сам запрос, а иногда и переписать.
> Получение данных из файла быстрее, чем из БД
Есть много случаев когда обращение к БД быстрее:
— запрос попал в кеш, выборка делается из ОЗУ, что априори на порядки быстрее чем чтение из файла.
— запрос в таблицу типа MEMORY, тут собственно опять нету обращения к диску, поэтому как и в предыдущем вариант на порядки быстрее.
— запрос «в индекс» будет быстрее в большинстве случаях, ибо индекс обычно «висит» в памяти, что в очередной раз быстрее на порядки чем обращение к диску
— …
Подобных оптимизаций со стороны БД достаточно много, чтобы все тут перечислять, стоит ли овчинка выделки?
> Если данные выборки из БД редко меняются и к этим данным обращается множество пользователей, то имеет смысл сохранить данные выборки в файл
И тут не согласен:
— если данные редко меняются и часто читаются — БД сама всё закеширует (для несложных запросов естественно)
— если данные и редко читаются, и редко меняются, то стоит лих их вообще куда-то кешировать?
— если запрос сложный и часто испольщуется, то:
1) можно кешировать данные в PHP, например с помощью APC или memcached
2) закешировать в таблицу типа MEMORY. Например, для материализованных вьюх.
Работа без объектов (без ООП) быстрее, чем работа с использованием объектов, примерно, в три раза
вы разрабатываете PHP4? В PHP 5.3 разница не такая существенная, а вот проект поддерживать несоизмеримо проще.
Инкремент инициализированной переменой i=0; ++i; быстрее, чем не инициализированной ++i
Это не должно быть оптимизацией, т. к. переменные надо инициализировать всегда.
Использование «отработавших» переменных быстрее, чем объявление новых
Попробуйте отладить код состоящий из переменных $a, $b, $i, $tmp, $temp,… Данное утверждение верно только в том случае, когда новое значение будет такого же типа как старое ;-)
Системы с дефектными чипсетами поставлялись только начиная с 9 января
P.S. А что делать тем у кого 3 диска и DVD/BluRay?
P.P.S. А если через год место закончится и захочется поставить свеженький 4Tb диск? отказаться от DVD/BluRay? Не выход
Лютики, наручники, порванный рот
Сколько раз, покатившись, моя голова
С переполненной плахи летела сюда, где...»
Извините, напомнило.
На Core i5-750 и PHP 5.3.3, результаты одинаковы: ~0.8с для миллиона(!) выводов, причем это не чистое время, т.к. есть оверхед из-за фора.
echo "текст {$row['id']} текст";Есть много случаев когда обращение к БД быстрее:
— запрос попал в кеш, выборка делается из ОЗУ, что априори на порядки быстрее чем чтение из файла.
— запрос в таблицу типа MEMORY, тут собственно опять нету обращения к диску, поэтому как и в предыдущем вариант на порядки быстрее.
— запрос «в индекс» будет быстрее в большинстве случаях, ибо индекс обычно «висит» в памяти, что в очередной раз быстрее на порядки чем обращение к диску
— …
Подобных оптимизаций со стороны БД достаточно много, чтобы все тут перечислять, стоит ли овчинка выделки?
> Если данные выборки из БД редко меняются и к этим данным обращается множество пользователей, то имеет смысл сохранить данные выборки в файл
И тут не согласен:
— если данные редко меняются и часто читаются — БД сама всё закеширует (для несложных запросов естественно)
— если данные и редко читаются, и редко меняются, то стоит лих их вообще куда-то кешировать?
— если запрос сложный и часто испольщуется, то:
1) можно кешировать данные в PHP, например с помощью APC или memcached
2) закешировать в таблицу типа MEMORY. Например, для материализованных вьюх.
Работа без объектов (без ООП) быстрее, чем работа с использованием объектов, примерно, в три раза
вы разрабатываете PHP4? В PHP 5.3 разница не такая существенная, а вот проект поддерживать несоизмеримо проще.
Инкремент инициализированной переменой i=0; ++i; быстрее, чем не инициализированной ++i
Это не должно быть оптимизацией, т. к. переменные надо инициализировать всегда.
Использование «отработавших» переменных быстрее, чем объявление новых
Попробуйте отладить код состоящий из переменных $a, $b, $i, $tmp, $temp,… Данное утверждение верно только в том случае, когда новое значение будет такого же типа как старое ;-)
P.S. КО подсказывает, что 20 = 1