>[оверквотинг удален]
>  }
>  vec.len = write;
> }
> Тут виден чёткий последовательный доступ к памяти, который очень хорошо ложиться на
> стратегии кеширования процессора, и мы видим, что это короче. Код со
> списками содержит практически такой же цикл, и я не вижу никаких
> существенных различий между этими циклами *с точки зрения*, простоты как основы
> *читабельности и возможности поддерживать код*. Но мы видим, что в случае
> списков, перед циклом и после цикла возникает та самая обработка краевых
> условий, о которых я говорил.

[add]
> Состоит в апдейте максимум двух указателей. Не четырех, нет...

Угу. Но это потому что списочная ячейка после удаления перестаёт существовать, отправляясь в свободную память в куче. Это очень часто не так, когда используется список с принудительной связью, чтобы снизить количество мелких аллокаций в куче (хотя это, я думаю, менее релевантно для языков со сборкой мусора, потому что им не надо вызывать free на каждую освобождаемую ячейку, плюс дефрагментация кучи тотальна и условно бесплатна). И в этом случае списочная ячейка продолжит существовать, но в "плохом" состоянии: она будет выглядеть как валидная списочная ячейка включённая в список. Поэтому её указатели стоит отресетить в NULL, или на саму себя (в зависимости от тонкостей реализации списков), а это удваивает количество изменяемых указателей при операциях удаления и приравнивает его к количеству изменяемых указателей в случае вставки. Это вряд ли существенно влияет на производительность, которая в любом случае упрётся в скорость DRAM, но код захламляет. Что опять же не очень важно, поскольку эти вещи всё равно выносятся в inline-функции, но разговор ведь начался с того, что синтаксис слайсов слишком заморочен, и вроде как списки выглядят лучше.