Pull to refresh
9
0
Хавило Дмитрий@widowmaker

User

Send message
Кагбе:
Системы с дефектными чипсетами поставлялись только начиная с 9 января
Забыл добавить, биос последний — версия 1.7.
Немного медленнее грузится винда, после загрузки несколько-минутный тупняк которого еще вчера небыло. Вчера ничего не ставил из софта и кроме новой серии 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? Не выход
У United States Department of Defense целых 10 блоков /8, зачем им столько, неужели Skynet?
Насколько я понял, имеются в виду «Программисты серверного приложения»
«Чёрные фары у соседних ворот
Лютики, наручники, порванный рот
Сколько раз, покатившись, моя голова
С переполненной плахи летела сюда, где...»

Извините, напомнило.
Можно dev ветку хрома, у меня сейчас версия 10.0.648.6, обновляется ~ раз в неделю
Может я енвнимательно слушал, но разве это не Heroes Kingdoms?
Имхо, аналогия не совсем корректная, разработчик игры из серии должен знать историю сета, он же не разносчик кофе или завхоз.
Как это разработчик Heroes (пусть даже Kingdoms) не знает кто делал первые 4 части, называет Heroes VI — FPS и сравнивает её со Старкрафтом. Кстати он не в курсе что IV-ую часть делал совсем не Ubisoft и именно из-за того что она считалась неудачной 3DO обанкротилась (в 2003м, а не в 90-ых) после чего серия была куплена Ubisoft. Бррррр…
Наверно первое — это дело привычки, мне со скобочками читабельнее, пользуюсь PHPStorm'ом :)
Вариант со скобочками предпочтительнее, т.к. он лучше читается и он надежнее, можно не думать правильно ли интерпретатор распарсит переменную в строке.
Только что проверил, разницы вообще нет.

<?
  $row = array('id' => 1297);
  $results = array();
  $tests = 1000000;

  $start = microtime(true);

  for($i = $tests; $i-- > 0;)
    echo $row['id'] , ' title';
  $results[] = (- $start + ($start = microtime(true)));

  for($i = $tests; $i-- > 0;)
    echo $row['id'] . ' title';
  $results[] = (- $start + ($start = microtime(true)));

  for($i = $tests; $i-- > 0;)
    echo "$row[id] title";
  $results[] = (- $start + ($start = microtime(true)));

  for($i = $tests; $i-- > 0;)
    echo "{$row['id']} title";
  $results[] = (- $start + ($start = microtime(true)));

  var_dump($results);
?>


На Core i5-750 и PHP 5.3.3, результаты одинаковы: ~0.8с для миллиона(!) выводов, причем это не чистое время, т.к. есть оверхед из-за фора.
а еще лучше помогать интерпретатору выделяя переменные фигурными скобками:
echo "текст {$row['id']} текст";
У нас в проекте несколько таблиц милионников размерами от сотен до гигабайт, запросы больше 0.2с редкость, да и те в моменты пиковой нагрузки. Индексы решают, главное правильно ими пользоваться, только расстановки индексов не всегда достаточно, частенько надо немного поправить сам запрос, а иногда и переписать.
> Получение данных из файла быстрее, чем из БД
Есть много случаев когда обращение к БД быстрее:
— запрос попал в кеш, выборка делается из ОЗУ, что априори на порядки быстрее чем чтение из файла.
— запрос в таблицу типа MEMORY, тут собственно опять нету обращения к диску, поэтому как и в предыдущем вариант на порядки быстрее.
— запрос «в индекс» будет быстрее в большинстве случаях, ибо индекс обычно «висит» в памяти, что в очередной раз быстрее на порядки чем обращение к диску
— …
Подобных оптимизаций со стороны БД достаточно много, чтобы все тут перечислять, стоит ли овчинка выделки?

> Если данные выборки из БД редко меняются и к этим данным обращается множество пользователей, то имеет смысл сохранить данные выборки в файл
И тут не согласен:
— если данные редко меняются и часто читаются — БД сама всё закеширует (для несложных запросов естественно)
— если данные и редко читаются, и редко меняются, то стоит лих их вообще куда-то кешировать?
— если запрос сложный и часто испольщуется, то:
1) можно кешировать данные в PHP, например с помощью APC или memcached
2) закешировать в таблицу типа MEMORY. Например, для материализованных вьюх.

Работа без объектов (без ООП) быстрее, чем работа с использованием объектов, примерно, в три раза
вы разрабатываете PHP4? В PHP 5.3 разница не такая существенная, а вот проект поддерживать несоизмеримо проще.

Инкремент инициализированной переменой i=0; ++i; быстрее, чем не инициализированной ++i
Это не должно быть оптимизацией, т. к. переменные надо инициализировать всегда.

Использование «отработавших» переменных быстрее, чем объявление новых
Попробуйте отладить код состоящий из переменных $a, $b, $i, $tmp, $temp,… Данное утверждение верно только в том случае, когда новое значение будет такого же типа как старое ;-)
Я помню 16777216, это 224, легко запоминается и ровно столько оттенков отображает большинство современных мониторов.
Это в какой интересно степени?

P.S. КО подсказывает, что 20 = 1

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity