1. Можно ли в немерли в самом примитивном случае определить когда объект будет уничтожен (например выход из видимости)
2. Быстрее ли создание объекта хештаблицы чем его очистка?
Имеет ли смысл попытаться сделать следующий вариант
{
def hash=hashtable();
.....
....
}
{
def hash=hashtable()
....
....
}
заменять на
static hashtables:array[struct {hashtable h, bool b}]();
def gethashtable()
{
findn(hashtables, h => h.b, hashtables.add(hashtable(), true))
}
def disprosehashtable(hash)
{
hash.Clear();
hash.b=false;
}
}
{
def hash=gethashtable();
....
...
...
disprosehashtable(hash);
}
{
def hash=gethashtable();
....
...
...
disprosehashtable(hash);
}
Здравствуйте, Аноним, Вы писали:
А>2. Быстрее ли создание объекта хештаблицы чем его очистка?
В долгосрочной перспективе выгоднее для системы в целом пересоздавать объекты, что бы
1 не было слишком много старых (gen2)
2 старые не содержали ссылки на новые (write barrier)
3 не попадали в LOH надолго (х32)
Проблема с write barrier актуальна для веб-приложений. Скажем, если тупо написать кеш на хештейбле, то на больших объемах он будет тупо тормозить сам по себе.
Для х32 есть такие соображения — если хештейбл маленький, его дешево пересоздать. Если большой, то его слишком дорого удерживать долгое время, хотя пересоздание будет так же довольно дорогим.
Большой хештейбл слишком быстро попадает LOH. Вот, на примере Dictionary
private int[] buckets;
private Dictionary<TKey, TValue>.Entry[] entries;
private struct Entry
{
public int hashCode;
public int next;
public TKey key;
public TValue value;
}
В сумме это означает ,что расход памяти на один элемент будет минимально равен 20 байт, если ключ-значение это референс тайп. То есть, с учетом границы 85кб, в LOH хештейбл попадет при количестве элементов всего чуть более 5 тысяч.
Если ключ это какой нибудь структура, то гораздо раньше — около 4000 экземпляров. А если значение так же будет структурой, то получается бедствие.
Если в хештейбл будет добавляться элементов от 10 тысяч, то в х32 LOH будет сильно фрагментироваться
1 из за переаллокаций
2 массив buckets так же попадет в LOH
Вообще, для быстрой работы GC незвисимо от разрядности платформы лучше избегать 1 больших объектов 2 долгоживущих объектов