веб, ASP, начало

[Пепел Феникса]

В пределах кода во время замера область видимости не изменяется.

из методов TestStringList и TestLinkedList вы не выходите, да?

А про два сравнения - у меня не три выхода, а четыре. Именно поэтому важно определить в каком направлении нужно двигаться

согласно вашему же коду, у вас 2&2, а не 2+2.
два последовательных сравнения, а не вложенные:

//1 - тут два выхода.
			if (index<position)
			{
				prevsteps=position-index;
				nextsteps=count-position+index;
			} else
			if (index>position)
			{
				prevsteps=count+position-index;
				nextsteps=0-position+index;
			} else {}
// 2 - тут тоже два выхода.
			if (prevsteps>nextsteps)
				SwitchToNext(nextsteps);
			else
			if (prevsteps<nextsteps)
				SwitchToPrev(prevsteps);
			else {}

вы зачем-то добавляете третью точку выхода.
и вместо одного сравнения за пару пытаетесь делать два.

я не спроста

if(a<b) { /*a<b*/ } else { /*a>=b*/ }

это привел, усложняете код на пустом месте.(и сами же ошиблись)
(в данной ситуации не может быть третьего выхода).

[OmegaBerkut]

Пепел Феникса
Про области видимости - я говорил об этом:

Сообщение от OmegaBerkut

Пепел Феникса
...
Если говорить об области видимости внутри кода коллекций - то у каждого класса свои переменные, и свои внутренние данные - и сводить обработку этих данных к погрешности ни в коем случае нельзя. Ибо если в LinkedList есть локальная переменная temp (скажем в функции AddLast), то на её создание и удаление так же будет затрачено время, которое так же необходимо учитывать. Тоже самое справедливо и для моего класса.

Да и потом, как вы рассчитываете время обработки создания/удаления переменных вне областей их видимости ? В прочем это не так уж и важно, просто интересно.
И вопрос по поводу сборки: какая разница, при какой сборке тестируется оба класса ? Для классов (правильнее говорить - объектов, потому что уже во время выполнения программы) внешние условия всё равно одинаковые.

Что касается количества выходов при сравнении:
1) первая точка выхода - количество шагов назад меньше количества шагов вперёд, значит двигаемся назад
2) вторая точка выхода - количество шагов вперёд меньше количества шагов назад, значит двигаемся вперёд
3) тут две под-точки, при которых количество шагов в обоих направлениях одинаково
3.1) текущий индекс равен запрашиваемому (для любого количества элементов списка), а это означает, что двигаться никуда не надо
3.2) запрашиваемый индекс находится в противоположной части карусели, что означает, что двигаться можно в любом направлении; эта точка выхода справедлива только для случаев, когда количество элементов списка нечётное (о чём я уже говорил).

То есть, пункт 3 - это целая ветка, которая в листинге у меня пустая.

[Alex11223]

Сообщение от OmegaBerkut

какая разница, при какой сборке тестируется оба класса ? Для классов внешние условия всё равно одинаковые.

Потому что никого не волнует какая в дебаге производительность, у пользователя ж релиз будет, зачем ему давать дебаг без оптимизаций.

И мало ли что там в другом классе, может ассерты и ifdef DEBUG на каждом шагу.

[OmegaBerkut]

Но можно и по другому:

if (prevsteps==0) // для случаев, когда мы уже в нужной позиции, равнозначно nextsteps==0
	return;
else
if (prevsteps<nextsteps)
{ /*двигаемся назад*/ }
else
{ /*двигаемся вперёд*/ }

В таком случае первая и последняя ветки перекрывают третьи точки выхода.

[Пепел Феникса]

Да и потом, как вы рассчитываете время обработки создания/удаления переменных вне областей их видимости ? В прочем это не так уж и важно, просто интересно.

я выношу этот вопрос, гарантировано все измерений.

И вопрос по поводу сборки: какая разница, при какой сборке тестируется оба класса ? Для классов внешние условия всё равно одинаковые.

в отладочной сборке нет оптимизаций(например нет инлайна), разрешена всякая хрень для отладчика(то что он не подключен, не важно, она есть в коде), + ассерты(то что они не выполнятся, не важно, они включены).

Что касается количества выходов при сравнении:

если быть точным там у вас может быть 3(+ развилка для второго выбора, если не первый).
не думал что придется это сказать, но вы составьте хоть блок схему на свой код.
а впрочем я сделал это за вас.
вот вариант с фейлом

вам самому не кажется что второе сравнение явно лишнее?(от которого есть ветка к фейлу)
оно бы имело смысл если бы для случаев когда проход по сторонам равен, у вас была бы особая реакция, иначе, привет дублирование кода на пустом месте.

вот проправленный вариант, стало чище не так ли?

Но можно и по другому:

для справки, после ретурна else не обязателен

[OmegaBerkut]

Пепел Феникса
Вот перепиленная функция. И да - у меня было дублирование возврата с моей предыдущей логикой, что в прочем на производительность влияет довольно таки мало - одна лишняя проверка, которая при её выполнении всегда false (ибо уже был отсеян этот случай).

public void SwitchToIndex(int index)
{
	int
		count=first.prev.pos+1, // если в списке нет элементов - NRE
		position=current.pos,
		prevsteps=0,nextsteps=0;
	// если index>count - произойдёт зацикливание по списку; поднимать отдельное условие для этого не целесообразно
	if (index<position)
	{
		prevsteps=position-index;
		nextsteps=count-position+index;
	} else
	if (index>position)
	{
		prevsteps=count+position-index;
		nextsteps=0-position+index;
	} else
		return; // возврат для случаев, когда нам не нужно никуда двигаться
	if (prevsteps<nextsteps)
		SwitchToPrev(prevsteps);
	else
		SwitchToNext(nextsteps);
}

[Пепел Феникса]

по этому же коду вторая блок схема и составлена.

я надеюсь вы сделали вывод из лишних условия и возможностей выстрелить себе в ногу.
насчет остального что я хотел до вас донести я не уверен.

в принципе, я считаю свою часть выполненной, я немного передал вам опыта, немного попытался предстеречь от повторения моих же ошибок.(около 9 лет за плечами, да-да, с 15 лет).
что дальше делать, дело ваше.

что в прочем на производительность

дело не в производительности, а в возможность совершить ошибку.

[OmegaBerkut]

Пепел Феникса
Теперь да, у меня такие же пропорции в результатах тестов, как и у вас (по коду к методу тестирования не должно быть претензий). Признаю свою ошибку по конфигурации сборки - банально не знал. И возвращаясь к моей фразе "померяемся, у кого меньше" - вы выграли (35-40%), что согласен спихнуть на ваш опыт. Я кстати так же учусь программировать с 15 лет (сейчас мне 20).
Вопрос в другом: почему в дебаге код из библиотек работает в два раза медленнее, чем в релизе ? При этом мой код работает одинаково и в дебаге, и в релизе.

Сообщение от Пепел Феникса

дело не в производительности, а в возможность совершить ошибку

Такая возможность есть у всех и всегда.
А на счёт аргументов и всего остального - мне просто интересны логические конструкции, так сказать, инсайд, и я только с удовольствием трачу на эту муть своё личное время. О чём уже когда то упоминал в разных словесных формах.

[Пепел Феникса]

Такая возможность есть у всех и всегда.

а зачем добавлять новую?

Вопрос в другом: почему в дебаге код из библиотек работает в два раза медленнее, чем в релизе ? При этом мой код работает одинаково и в дебаге, и в релизе.

1)их код имеет ассерты.
2)их код следует гайдлайнам и не имеет доступа к полям классов, все через свойства.(что не в релизе замедляет доступ)

[OmegaBerkut]

Пепел Феникса
Добавлять новую возможность ошибиться лишь для того, что бы учиться на этих ошибках - в буквальном смысле получать опыт (это касается не только прогаммирования). А в качестве бонуса - понимание, как конкретный класс устроен внутри, и как его можно улучшить в каком либо смысле. И да: я ведь не пытаюсь переписать всё, а только то, о чём имею хоть какое то представление. В этом мой интерес.
А брать готовое и использовать без понимания устройства - я так не умею, и не люблю.