.NET: Что такое типичный сборщик "мусора" наверху?
5% времени выполнения потрачены на GC? 10%? 25%?
Спасибо.
7 ответов
http://code.activestate.com/recipes/65212/
def base10toN(num,n):
"""Change a to a base-n number.
Up to base-36 is supported without special notation."""
num_rep={10:'a',
11:'b',
12:'c',
13:'d',
14:'e',
15:'f',
16:'g',
17:'h',
18:'i',
19:'j',
20:'k',
21:'l',
22:'m',
23:'n',
24:'o',
25:'p',
26:'q',
27:'r',
28:'s',
29:'t',
30:'u',
31:'v',
32:'w',
33:'x',
34:'y',
35:'z'}
new_num_string=''
current=num
while current!=0:
remainder=current%n
if 36>remainder>9:
remainder_string=num_rep[remainder]
elif remainder>=36:
remainder_string='('+str(remainder)+')'
else:
remainder_string=str(remainder)
new_num_string=remainder_string+new_num_string
current=current/n
return new_num_string
Вот еще один из тех же ссылок
def baseconvert(n, base):
"""convert positive decimal integer n to equivalent in another base (2-36)"""
digits = "0123456789abcdefghijklmnopqrstuvwxyz"
try:
n = int(n)
base = int(base)
except:
return ""
if n < 0 or base < 2 or base > 36:
return ""
s = ""
while 1:
r = n % base
s = digits[r] + s
n = n / base
if n == 0:
break
return s
Когда вы предоставляете служебные функции и все ваши методы являются статическими, я рекомендую использовать статические методы в статическом классе.
Когда вы хотите предоставить служебные методы, которые просто касаются вашего экземпляра, я рекомендую использовать статические методы в нестатическом классе. Например:
var myClass = MyClass.Create();
var myClass = MyClass.Parse("serialized.MyClass");
Как говорили другие, это зависит. Но, только для вашего чтения:
Кроме того, мой вопрос к вам будет - почему вы беспокоитесь о накладных расходах (или вам просто любопытно с академической точки зрения)? Если есть конкретная ситуация, которая, по вашему мнению, повлияет на производительность вашего приложения, пожалуйста, спросите об этой ситуации, и вы можете получить лучшие ответы. В остальном, есть более важные вещи, о которых стоит беспокоиться (с точки зрения производительности), чем сборщик мусора - первым является ваш собственный код/алгоритмы/и т.д.
Накладные расходы сильно различаются. На самом деле нецелесообразно сводить проблемную область к «типичным сценариям», потому что накладные расходы GC (и связанных функций, таких как финализация) зависят от нескольких факторов:
- Вариант GC, который использует ваше приложение (влияет на то, как ваши потоки могут быть заблокированы во время а GC).
- Ваш профиль распределения, включая то, как часто вы выделяете (GC запускается автоматически, когда запрос на выделение требует больше памяти) и профиль времени жизни объектов (коллекции поколения 0 являются самыми быстрыми, коллекции поколения 2 медленнее, если вы вызываете много генерации 2 коллекции ваши накладные расходы увеличатся).
- Профиль времени жизни финализируемых объектов, потому что у них должны быть завершены финализаторы, прежде чем они будут допущены к сбору.
Влияние различных точек на каждую из этих осей релевантности может быть проанализировано (и, вероятно, есть более важные области, которые я не припомню в голове) - так что проблема действительно в том, «как вы можете уменьшить эти оси релевантности «общему сценарию»? »
В основном, как говорили другие, это зависит от обстоятельств. Или «достаточно низкий, чтобы не беспокоиться об этом, пока он не появится в отчете профилировщика».
Это полностью зависит от приложения. Сборка мусора выполняется по мере необходимости, поэтому чем чаще вы выделяете большие объемы памяти, которая впоследствии становится мусором, тем чаще ее нужно запускать.
Он может даже упасть до 0%, если вы распределяете все заранее и никогда не выделяете никаких новых объектов.
В типичных приложениях, я думаю, ответ очень близок к 0% времени, которое тратится на сборщик мусора.
Да, сборщик мусора будет тратить около X% времени на сбор при усреднении по всем приложениям во всем мире. Но это не обязательно означает, что время идет на накладные расходы. Что касается накладных расходов, вы действительно можете подсчитать только время, которое осталось бы после освобождения эквивалентного объема памяти на неуправляемой платформе.
С учетом этого фактические накладные расходы отрицательные , но сборщик мусора сэкономит время, освобождая несколько блоков памяти партиями. Это означает меньшее количество переключений контекста и общее повышение эффективности.
Кроме того, начиная с .Net 4 сборщик мусора выполняет большую часть своей работы в другом потоке, который не так сильно прерывает ваш текущий выполняющийся код. Поскольку мы все больше и больше работаем с многоядерными машинами, где ядро может даже время от времени бездействовать, это большое дело.
Эта запись в блоге содержит интересное исследование в этой области.
Вывод плаката? Что накладные расходы были незначительными для его примера.
Итак, куча сборщика мусора работает настолько быстро, что в реальной программе, даже в тесных циклах, вы можете использовать замыкания и делегаты, даже не задумываясь (или даже несколько наносекунд). Как всегда, работайте над чистым и безопасным дизайном, а затем профилируйте, чтобы выяснить, где находятся накладные расходы.
Посмотрите видео Red Gate здесь. Лучшее объяснение GC, с которым я сталкивался.
Это действительно может варьироваться. Посмотрите на эту демонстрационную краткую, но полную программу, которую я написал:
http://nomorehacks.wordpress.com/2008/11/27/forcing-the-garbage-collector/
это показывает эффект больших сборок мусора gen2.