Я имел ввиду высокие настройки: антиалиасинги всякие, фильтрации анизотропные, повышенная детализация, DirectX 11 и прочая. Работает без тормозов.
Во время бета-теста ESO у меня Optimus запускал игру на встроенной видеокарте и я долго думал почему оно так сильно тормозит, пока принудительно не включил дискретную. Возможно у вас с Civ 5 такая же фигня происходит.
На каждой итерации ищет индекс во внутренней хэш таблице.
Оценочно, сложность последней операции выражалась бы суммой арифметической прогрессии n*(n+1)/2 т.е. и имела бы порядок O(n2), если бы при поиске значения по индексу перебиралась бы вся хэш таблица. На самом деле, перебираются не все значения, а только часть их, поэтому сложность будет варьироваться от O(n) до O(n2). И для больших массивов, она будет ближе к, O(n). Но даже в этом случае, перебор массива с доступом по ключу — более ресурсоемкая операция.
На самом деле сложность тут будет O(n), а не O(n2) во всех случаях, потому что вряд ли разработчики PHP забили на качество хэширования и обычные числовые индексы имеют весьма слабую вероятность попасть в один bucket.
Ну т.е. не будет перебора даже части значений, потому что в bucket-е будет ровно один элемент. В этом и смысл хэш-таблицы.
Тут вопрос не в обвязке этих операций, а в алгоритмической сложности. Автор топика утверждает что сложность выборки из хэш-таблицы — O(n) что есть неправда.
Это одна из базовых структур данных, используемая в подавляющем большинстве языков программирования. О ней правда стоит почитать хотя бы вики и знать ее сложность.
int zend_hash_index_find(const HashTable *ht, ulong h, void **pData)
{
uint nIndex;
Bucket *p;
nIndex = h & ht->nTableMask;
p = ht->arBuckets[nIndex];
while (p != NULL) {
if ((p->h == h) && (p->nKeyLength == 0)) {
*pData = p->pData;
return SUCCESS;
}
p = p->pNext;
}
return FAILURE;
}
Вот это вообще похоже на выборку из самой обычной-преобычной хэш-таблицы. Если это так, то в arBuckets хранится в среднем 1 элемент, и итоговая сложность выборки одного элемента по индексу — константная — O(1).
Вы не до конца понимаете «однопоточную» природу работы интерпретатора JS. Функции выполняются интерпретатором по-очереди, каждая — от начала и до конца. Если функция УЖЕ выполняется интерпретатором, ничто прервать ее не может. На этом основана одна из наиболее сильных сторон JS — асинхронность выполнения запросов полностью без всяких паттернов синхронизации потоков, присущих «большим» языкам (мьютексы, семафоры и т.д.).
setTimeout принимает два параметра — callback и timeout. И ставит на выполнение в основной интерпретатор функцию callback, которая должна отработать когда интерпретатор освободится, но не меньше чем через время timeout. Если к этому времени вы вызвали clearTimeout соответствующему таймауту, то выполнения функции не будет. При этом clearTimeout вы можете вызвать только в одной из функций, чье выполнение по очереди было раньше, чем выполнение callback-функции таймаута.
При чем тут замыкания, я не совсем понимаю. Функция в JS либо выполняется до конца, либо падает с исключением. Или вы можете влепить что-то вроде while(1) {} в коде callback-функции но в этом случае вы тупо повесите интерпретатор. Совсем. И до конца. В каком месте тут может происходить утечка памяти, я тоже не понимаю.
Что вы подразумеваете под «замыканиями»? Мне всегда казалось что «замыкание» — это когда функция внутри себя имеет ссылку на переменную, которая не определена внутри нее.
Вы имеете ввиду что если callback-функция таймаута свалится с исключением, то GC не сможет собрать ее?
Я просто не понимаю, что может «пойти не так» внутри callback-функции?
Хм, «раздербанил» код теста с помощью javap. Код второго цикла гораздо больше и наличие имеется imul и dup_x2, в отличие от кода первого.
Есть предположение что массив хранится в «одну линию», и, поскольку во-втором массиве идет обращение к элементам массива не по-порядку, строка за строкой, а вразнобой, то появляется дополнительный код, вычисляющий смещение.
> Я помню времена, когда программисты отлично понимали друг друга. Каждый, кто умел программировать — знал как написать Makefile и bash скрипт. Сейчас же, человек который ничего не видел кроме Java и Maven входит в ступор, когда ему присылают Rake-файл.
Джо Армстронг бурчит, как старушка у подъезда: "А вот при Сталине..." И c чего-бы вдруг Java-программист, использующий Maven, должен понимать Rake(!)-файлы.
Во время бета-теста ESO у меня Optimus запускал игру на встроенной видеокарте и я долго думал почему оно так сильно тормозит, пока принудительно не включил дискретную. Возможно у вас с Civ 5 такая же фигня происходит.
На самом деле сложность тут будет O(n), а не O(n2) во всех случаях, потому что вряд ли разработчики PHP забили на качество хэширования и обычные числовые индексы имеют весьма слабую вероятность попасть в один bucket.
Ну т.е. не будет перебора даже части значений, потому что в bucket-е будет ровно один элемент. В этом и смысл хэш-таблицы.
Вот это вообще похоже на выборку из самой обычной-преобычной хэш-таблицы. Если это так, то в arBuckets хранится в среднем 1 элемент, и итоговая сложность выборки одного элемента по индексу — константная — O(1).
setTimeout принимает два параметра — callback и timeout. И ставит на выполнение в основной интерпретатор функцию callback, которая должна отработать когда интерпретатор освободится, но не меньше чем через время timeout. Если к этому времени вы вызвали clearTimeout соответствующему таймауту, то выполнения функции не будет. При этом clearTimeout вы можете вызвать только в одной из функций, чье выполнение по очереди было раньше, чем выполнение callback-функции таймаута.
При чем тут замыкания, я не совсем понимаю. Функция в JS либо выполняется до конца, либо падает с исключением. Или вы можете влепить что-то вроде while(1) {} в коде callback-функции но в этом случае вы тупо повесите интерпретатор. Совсем. И до конца. В каком месте тут может происходить утечка памяти, я тоже не понимаю.
И что значит «задержка» выполнения кода?
Я просто не понимаю, что может «пойти не так» внутри callback-функции?
Зарегистировал патент на бороду и начал подавать в суд на бородатых
Есть предположение что массив хранится в «одну линию», и, поскольку во-втором массиве идет обращение к элементам массива не по-порядку, строка за строкой, а вразнобой, то появляется дополнительный код, вычисляющий смещение.
Джо Армстронг бурчит, как старушка у подъезда: "А вот при Сталине..." И c чего-бы вдруг Java-программист, использующий Maven, должен понимать Rake(!)-файлы.