Просмотрев код, я наткнулся на ряд новых частных общих переменных (типа Hashtables (Of String), инициализированных в объявлении), добавленных в частичный класс для очень большого (DataContext-производного) класса. Это кажется мне разумным в некотором смысле, потому что они никогда не меняются, и эти общие переменные гарантируют, что они не будут повторно инициализироваться каждый раз, когда вызывается функция. Однако эти переменные являются, которые используются только в пределах одной функции класса, и я боюсь, что частное пространство имен этого производного класса DataContext становится довольно загрязненным, и такие вещи, которые подвергаются на таком высоком уровне, могут быть смущая других, читающих код в будущем. Было ли отрицательное влияние на производительность этих локальных переменных внутри функции, где они используются, или есть ли лучший способ справиться с этим? В основном мы используем эти 3 хэш-таблицы для определения того, изменилось ли что-либо внутри определенных подмножеств свойств (с использованием GetModifiedMembers, а затем с помощью функции Overlaps хешета, чтобы увидеть, соответствуют ли какие-либо из измененных членов членам, которых мы заботимся).Частные общие переменные против локальных переменных/Замедление пространства имен и производительность?
Редактировать: Я сбежал и нашел время, чтобы написать собственную тестовую программу, в которой подтверждается, что существует стоимость использования локальных переменных (которые, как я полагаю, применяется в целом ко всем случаям), я сомневаюсь, что есть случай, когда общий переменная будет медленнее, если с помощью общей переменной не требует некоторой дополнительной логики, чтобы сделать это правильно):
Sub Main()
Dim st As New Stopwatch()
Dim specialCount As Integer = 0
Dim r As New Random()
Dim params As Integer()
ReDim params(0 To 9)
st.Start()
For i As Integer = 1 To 100000
For j As Integer = 0 To 9
params(j) = r.Next(100)
Next
If IsSpecialShare(params) Then specialCount += 1
Next
st.Stop()
Console.WriteLine("Shared: " & specialCount)
Console.WriteLine(st.Elapsed.ToString())
st.Reset()
specialCount = 0
st.Start()
For i As Integer = 1 To 100000
For j As Integer = 0 To 9
params(j) = r.Next(100)
Next
If IsSpecialLocal(params) Then specialCount += 1
Next
st.Stop()
Console.WriteLine("Local: " & specialCount)
Console.WriteLine(st.Elapsed.ToString())
End Sub
Dim specialListShared As New HashSet(Of Integer)(New Integer() {2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41})
Private Function IsSpecialLocal(ByVal paramList As IEnumerable(Of Integer)) As Boolean
Dim specialListLocal As New HashSet(Of Integer)(New Integer() {2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41})
Return specialListLocal.Overlaps(paramList)
End Function
Private Function IsSpecialShare(ByVal paramList As IEnumerable(Of Integer)) As Boolean
Return specialListShared.Overlaps(paramList)
End Function
Пример вывода:
Shared: 75232
00:00:00.0408223
Local: 75018
00:00:00.1344628
таким образом, в данном конкретном случае, используя локальную переменную стоит около 200% , Но в большинстве случаев (включая мое собственное) время, вероятно, незначительно по сравнению с общей задачей. Поэтому, я думаю, теперь возникает вопрос, как люди обычно чувствуют себя в улучшении обслуживания кода за счет незначительных, но известных эффектов производительности?
Я не думаю, что меня беспокоит реальная измеримая производительность здесь, поскольку разница, вероятно, будет невыяснимо малой. И есть рекомендации, основанные на производительности, независимо от необходимости профилировать отдельные случаи. Вот что я здесь делаю. Например, вы обычно должны использовать строго типизированные переменные вместо ссылок на объекты, где это возможно, из-за стоимости бокса и бокса. Мой вопрос, аналогичный тому, заключается в том, есть ли значительная стоимость для рассмотрения при использовании локальных переменных, а не общих переменных. Выгод/затрат? – BlueMonkMN
На самом деле это константа, но (хотя VB.NET допускает локальные константы), невозможно объявить константу с таким значением, поэтому мы должны объявить переменную. И тогда мы сталкиваемся с аналогичным вопросом: стоит ли накладные расходы на наличие дополнительных экземпляров, которые стоят того, чтобы не загрязнять пространство имен класса. Это действительно постоянная, применимая только к этой конкретной функции. Это всего лишь список имен свойств для свойств, значения которых обрабатываются внутри этой функции. – BlueMonkMN
Тогда я бы объявил его как статическую локальную переменную. Накладные расходы, вероятно, очень малы, поэтому стоит не загрязнять пространство имен класса, если только не создаются миллионы объектов этого типа. (1 миллион объектов = 1 миллион копий вашей статической переменной) –