Правило 90/10 для управления памятью? [закрытый]
не уверен, что это то, что тебе нужно, но вот как бы я это сделал:
DECLARE @cols NVARCHAR(MAX)
,@table NVARCHAR(MAX)
,@sql NVARCHAR(MAX)
,@X INT = 1
WHILE @X < (
SELECT MAX(ROWID) FROM
(
SELECT quotename(COLUMN_NAME) col
,ROW_NUMBER()over(ORDER BY COLUMN_NAME) ROWID
FROM INFORMATION_SCHEMA.COLUMNS A
inner join INFORMATION_SCHEMA.TABLES B
on A.TABLE_NAME = B.TABLE_NAME
where TABLE_TYPE = 'BASE TABLE'
and DATA_TYPE = 'Float'
) AS X
WHERE ROWID < 10
)
BEGIN
SET @cols =
(SELECT col FROM
(
SELECT quotename(COLUMN_NAME) col
,ROW_NUMBER()over(ORDER BY COLUMN_NAME) ROWID
FROM INFORMATION_SCHEMA.COLUMNS A
inner join INFORMATION_SCHEMA.TABLES B
on A.TABLE_NAME = B.TABLE_NAME
where TABLE_TYPE = 'BASE TABLE'
and DATA_TYPE = 'Float'
) AS X
WHERE ROWID = @X
)
SET @table =
(SELECT tablename FROM
(
SELECT quotename(A.TABLE_NAME) tablename
,ROW_NUMBER()over(ORDER BY COLUMN_NAME) ROWID
FROM INFORMATION_SCHEMA.COLUMNS A
inner join INFORMATION_SCHEMA.TABLES B
on A.TABLE_NAME = B.TABLE_NAME
where TABLE_TYPE = 'BASE TABLE'
and DATA_TYPE = 'Float'
) AS X
WHERE ROWID = @X
)
Set @sql = 'SELECT MAX(CASE Charindex(''.'',' + @cols + ')
WHEN 0 THEN 0
ELSE
Len (Cast(Cast(Reverse(CONVERT(VARCHAR(50), ' + @cols + ', 128)
) AS FLOAT) AS BIGINT))
END) AS MAX_LENGTH
,MAX(CASE Charindex(''.'',' + @table + ')
WHEN 0 THEN 0
ELSE
Len (Cast(Cast(Reverse(CONVERT(VARCHAR(50), ' + @table + ', 128)
) AS FLOAT) AS BIGINT))
END) AS MAX_LENGTH'
PRINT(@sql)
SET @X = @X +1
END
6 ответов
Поскольку этот случай слишком редок. Почти никакой метод не изолируется. Они все принимают объекты снаружи или создают объекты и раздают их.
Метод, который не получает доступ ни к каким полям, не делает имеет параметры и не возвращается, что-то ничего не может сделать.
Вместо этого GCs концентрируются на наиболее распространенном случае (90%) и попытка сохранить те 90% (недолгие временные объекты) под контролем. Это означает, что в общем падеже, у Вас есть меньше объектов проверить, и остальное не имеет значения так очень. Затем, Вы используете возрастающую развертку (таким образом, можно работать в небольших спринтах, которые прерывают только в течение короткого момента).
Я когда-то попытался придумать лучший алгоритм GC и потерпел полный провал. Они используют подход, который граничит с тайным. Документ о Настройке производительности Java 5 GC должен дать Вам некоторое представление. И в Википедии существует, конечно, статья GC.
К чему это сводится: Используя GC может даже быть быстрее, чем наличие традиционного выделения памяти и освобождение схемы. Думайте о классическом алгоритме, который просто определяет местоположение любого достижимого объекта и копирует его в новое место. Если Вы только что забыли о большом количестве объектов (скажите, 90% всех выделенных объектов), этот алгоритм просто должен проверить остальных (10%). Что-либо, чего это не может достигнуть, неважно, каким количеством это может быть, не будет иметь значения. Теперь можно сказать, что копирование является дорогим, но a) это не верно; сегодня средний настольный ЦП может скопировать 40 МБ меньше чем в 100 мс и b) копирование защитит Вас от фрагментации, таким образом, это будет на самом деле хорошая вещь.
"Большинство программистов соглашается, что сборка "мусора" является большой вещью, и в большинстве приложений определенно стоит издержек".
Широкие обобщения...
Если Вы создадите объект, который Вы ожидаете, то будет использоваться только в контексте одного вызова метода за один раз, и это не имеет никакого завершения, то я рекомендовал бы использовать тип значения вместо ссылочного типа на языках, которые делают это различие. Например, в C# Вы могли объявить свой объект как a struct вместо a class. Затем Ваше короткое время жизни, локальные для метода экземпляры будут выделены на стеке, а не "куче", и они будут освобождены implicity момент возвраты метода.
И эта техника может пойти еще больше, что Ваша исходная идея, потому что структура может быть передана другим методам без беспокойства о повреждении пожизненного анализа.
Для массива, как в вопросе, можно использовать stackalloc команда для достижения этого эффекта.
Что Вы описываете как детерминированные операторы удаления для того, чтобы не выходить из объектов, современные реализации GC делают справедливо эффективно. Большинство выделенных объектов выделено от пулов и удалено очень эффективно на выходе метода - очень немногие заканчивают на медленнее к "куче" GC.
Это в действительности производит тот же эффект, как Вы описываете с меньшим количеством вмешательства программиста. И потому что сборщик "мусора" является автоматическим, позволяет меньше объема для человеческой ошибки (что, если Вы удалили что-то, для которого ссылка была все еще сохранена).
Это, кажется, точно, как D управляет памятью. Его собравший "мусор", позволяя Вам конкретно удалить объекты, когда Вы хотите или даже сторониться GC все вместе в пользу malloc / свободный. Ограниченное по объему ключевое слово, кажется, делает то, что Вы хотите на стеке, хотя я не уверен, выделяет ли это на самом деле объект на стеке или "куче".
Быстрое примечание по, "очевидно, больше необходимый": Дело не в этом легкий ;)
[...]
Foo() {
someGlobalList.add(this);
}
[...]
Кроме этого, Ваша идея способности вручную удалить большие штуки является imo хороший. Насколько я понимаю это по крайней мере частично реализовано на современных языках (например. using в C#, который печально на самом деле не освобождает). Однако не до градуса Вы желаете.