Оптимизация?
От: Аноним  
Дата: 10.10.13 15:07
Оценка:
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);

}
Re: Оптимизация?
От: CodingUnit Россия  
Дата: 10.10.13 16:37
Оценка:
Здравствуйте, Аноним, Вы писали:

А>1. Можно ли в немерли в самом примитивном случае определить когда объект будет уничтожен (например выход из видимости)

А>2. Быстрее ли создание объекта хештаблицы чем его очистка?

А>Имеет ли смысл попытаться сделать следующий вариант


Какие то совершенно ненужные оптимизации как мне кажется в .net языке и только лишний код создают, в высокоуровневых языках об этом не думают.
Re: Оптимизация?
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.10.13 16:41
Оценка:
Здравствуйте, Аноним, Вы писали:

А>1. Можно ли в немерли в самом примитивном случае определить когда объект будет уничтожен (например выход из видимости)


Для этого есть интерфейс IDisposable и макрос using.

А>2. Быстрее ли создание объекта хештаблицы чем его очистка?


Зависит от задачи. Внутри хэш-таблицы создается массив бакетов память под который, при увеличении элементов, перезанимается. Если хэш-таблица многократно переиспользуется, этот массив наберет некий достаточно большой размер и перезаемов памяти в дальнейшем не будет.

С другой стороны, если после "набивки" хэш-таблицу нужно куда-то передавать, то проще создавать новые хэш-таблицы.

В общем и целом разрица не велика.

А>Имеет ли смысл попытаться сделать следующий вариант...

А>заменять на...

Точно, не стоит. И вообще, оптимизировать что-то имеет смысл только если ясно, что это узкое место. Ну, а когда это ясно, то и вопрос уже не будет стоять. Так что лучше подружиться с профайлером.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Оптимизация?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.10.13 10:35
Оценка:
Здравствуйте, Аноним, Вы писали:

А>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 долгоживущих объектов
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.