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

[OmegaBerkut]

Пепел Феникса
Я не отрицаю то, что результат худший, но и сами поймите, моим результатм два года, мало ли что за два года M$ изменил в своих исходниках. Может как раз и выполнил ту самую оптимизацию методом закольцовывания списка.

А "кучу индексов" я и не использовал.
Я один раз вызвал рандом, сохранив результат в переменную; а потом переменную использовал для доступа в списки. И так каждый раз при новой итерации. Без дополнительного массива.

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

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

А "кучу индексов" я и не использовал.
Я один раз вызвал рандом, сохранив результат в переменную; а потом переменную использовал для доступа в списки. И так каждый раз при новой итерации. Без дополнительного массива.

как же вы тестировали тогда? О_о

сделал одно обращение в свой класс, сделал одно в стандартный? так чтоль?
массив тут нужен для кучи обращений в пределах одной итерации теста.
(за каждый тест проходило 5000 * 100 обращений к списку)

я вам уже говорил, смотрите код теста, он справедлив полностью.
и да, за 2 года код списка по сути не менялся у МС.(базовая часть уж точно)


на самом деле я вас понимаю, очень напоминает мое старое желание написать свою альтернативу STL для С++, что было удобнее и не медленнее.
написать свой язык. опыт оно дало, но вот реального профита нет.
сделать свое с преферансом и куртизанками сейчас я оцениваю сразу, а могу ли я сделать лучше.
для связанного списка нельзя применять ElementAt от Linq, он слишком медленный.
свой же метод очень быстрый.

[OmegaBerkut]

Пепел Феникса
Если использовать двусвязный закольцованный список, при этом хранить во всех элементах ссылку на первый элемент, то при обращении по индексу я могу точно определить минимальное количество шагов в определённую сторону по списку, что бы вытащить конкретный индекс. В теории это уменьшит количество вариантов, при которых мне нужно будет обходить весь список, а так же уменьшит максимальное количество переходов по списку.
Единственная проблема - выход из цикла. Если у меня не будет дополнительной информации об общем количестве элементов - то мой цикл будет так же закольцован в пределах этого списка. Вот я сейчас сижу гадаю, как можно наиболее эффективно выйти из этого круга. Есть вариант в каждом элементе хранить общее количество, но при добавлении нужно будет увеличивать это число у всех. В C++ есть такое понятие, как адрес переменной, если такое есть в шарпе - будет очень здорово; тогда при однократном увеличении переменной автоматически будет тоже самое число у всех остальных элементов.
Если же такой плюшки нет - то придётся ещё подумать, по тестировать, поколдовать.

[OmegaBerkut]

Точно, общее количество будет валяться в first.prev.position

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

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

Пепел Феникса
Если использовать двусвязный закольцованный список, при этом хранить во всех элементах ссылку на первый элемент, то при обращении по индексу я могу точно определить минимальное количество шагов в определённую сторону по списку, что бы вытащить конкретный индекс. В теории это уменьшит количество вариантов, при которых мне нужно будет обходить весь список, а так же уменьшит максимальное количество переходов по списку.
Единственная проблема - выход из цикла. Если у меня не будет дополнительной информации об общем количестве элементов - то мой цикл будет так же закольцован в пределах этого списка. Вот я сейчас сижу гадаю, как можно наиболее эффективно выйти из этого круга. Есть вариант в каждом элементе хранить общее количество, но при добавлении нужно будет увеличивать это число у всех. В C++ есть такое понятие, как адрес переменной, если такое есть в шарпе - будет очень здорово; тогда при однократном увеличении переменной автоматически будет тоже самое число у всех остальных элементов.
Если же такой плюшки нет - то придётся ещё подумать, по тестировать, поколдовать.

задумайтесь почему нода и сам список у МС разделены.
при этом им не нужны индексы каждой ноды( у вас кстати при удалении элемента посреди списка надо пересчитывать все индексы)

закольцовывание списка только усложнит его.

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

ну а расширить LinkedList для кэширования тоже можно было

[OmegaBerkut]

Пепел Феникса
Как тестировал:
Пять тысяч итераций доступа к созданным спискам. На каждой итерации

request=rnd.Next(500);
strdata=List<request>; // правильного синтаксиса уже не помню
strdata=mylist.ItemFromIndex(request)

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

как я и говорил, тестирование не было верным.

[OmegaBerkut]

Пепел Феникса
Где же оно не верно ?
Я меряю количество мили/микро секунд для однократного доступа, суммирую пять тысяч раз, для своего списка в одну переменную, для стандартного - в другую. Перед доступом timer start, сразу после доступа - timer stop. И так самостоятельно для своего и стандартного списков.

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

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

+ бесполезно мерять слишком малые величины, у вас погрешность все съедает.

[OmegaBerkut]

Пепел Феникса
Да читал я ваш код: у вас каждый список тестируется по отдельности, и оба теста суммируются по количеству итераций, и в придачу массив индексов.
Как дела я

Псевдокод
получить рандомное число
обнулить и запустить таймер
обратиться в стандартный список
остановить таймер
прибавить значение таймера к сумме скорости обращения в стандартный список
обнулить и запустить таймер
обратиться в свой список
остановить таймер
прибавить значение таймера к сумме скорости обращения в свой список
вернуться в начало цикла

конец псевдокода

И так пять тысяч раз. Условия тестирования одинаковые для обоих коллекций. Погрешность на уровне +/- 0.5 % ? Не смешите.