Здравствуйте, _NN_, Вы писали:

_NN>Тогда мы получаем лишний расход в виде Interlocked.Increment и выведем лог только после того как вся работа окончится в отличии от начального кода.

Interlocked.Increment это вообще мелочи, можно пренебречь. Внутри Parallel.ForEach тоже свои Interlocked.Increment есть, если уж на то пошло.

По поводу лога — если уж очень хочется, чтобы логировал как можно раньше, то сделай враппер для своей enumerable, который на последнем MoveNext будет сразу счётчик в лог писать.

Здравствуйте, _NN_, Вы писали:

_NN>Как вы решаете эту задачу ?

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

Здравствуйте, _NN_, Вы писали:

int count = 0;

Parallel.ForEach(enumerable.Select(i => { _count++, return i; }), element =>
{
  Logger.Info($"Running task {element}");
});

Logger.Info($"Run {count} tasks");

Здравствуйте, _NN_, Вы писали:


_NN>Тогда мы получаем лишний расход в виде Interlocked.Increment и выведем лог только после того как вся работа окончится в отличии от начального кода.

Interlocked.Increment дешевле, чем таски создавать. И вообще Interlocked.Increment — довольно дешёвая штука. Если таски настолько короткие, что начинает играть роль лишний Interlocked.Increment, и вообще, если ты его замечаешь, то пора переходить к частным решениям конкретно для этого места в конкретном коде.

Здравствуйте, kov_serg, Вы писали:

_>Здравствуйте, _NN_, Вы писали:

_NN>>Как вы решаете эту задачу ?
_>

_>int count = enumerable.Count;
_>Logger.Info($"Run {count} tasks");
_>

У IEnumerable enumerable нет Count, иначе не было бы вопроса.
А вызов Enumerable.Count() приведёт к двойному обходу перечисления, что тоже не подходит.

Здравствуйте, kov_serg, Вы писали:

_>Здравствуйте, _NN_, Вы писали:

_NN>>У IEnumerable enumerable нет Count, иначе не было бы вопроса.
_>Что мешает добавить в свой интерфейс с количеством элементов.
_>Вы же это список заполняли как-то.

Ну к примеру у меня LINQ выражение какое-нибудь.

_NN>>А вызов Enumerable.Count() приведёт к двойному обходу перечисления, что тоже не подходит.
_>Почему? Пока идёт выполнение ваших задач, что мешает пройтись по списку еще раз? (Кроме религиозных соображений)

Это если такая возможность есть.
Не каждый IEnumerable даст пройтись два раза без последствий.

Имеется код вида:

List<Task> tasks;

foreach (var element in enumerable)
{
  tasks.Add(Task.Run( () => {} ) );
  Logger.Info($"Running task {element}");
}

Logger.Info($"Started {tasks.Count} tasks");
Task.WaitAll(tasks.ToArray());

Недостаток очевиден, мы создаём таск на каждый элемент, и лучше использовать Parallel.ForEach.
Однако с помощью Parallel.ForEach невозможно получить количество элементов.
В вышеприведённом примере мы их получаем неявно за счёт использования List.

Как вариант можно хранить переменную и автономно увеличивать:

int count = 0;

Parallel.ForEach(enumerable, element =>
{
  Interlocked.Increment(ref count);
  Logger.Info($"Running task {element}");
});

Logger.Info($"Run {count} tasks");

Тогда мы получаем лишний расход в виде Interlocked.Increment и выведем лог только после того как вся работа окончится в отличии от начального кода.

Как вы решаете эту задачу ?

Здравствуйте, _NN_, Вы писали:


_NN>Как вы решаете эту задачу ?
не совсем понятно зачем, но может это поможет?
https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.parallelloopstate?view=net-6.0

Здравствуйте, _NN_, Вы писали:

_NN>Как вы решаете эту задачу ?

int count = enumerable.Count;
Logger.Info($"Run {count} tasks");

Здравствуйте, _NN_, Вы писали:

_NN>У IEnumerable enumerable нет Count, иначе не было бы вопроса.
Что мешает добавить в свой интерфейс с количеством элементов.
Вы же это список заполняли как-то.

_NN>А вызов Enumerable.Count() приведёт к двойному обходу перечисления, что тоже не подходит.
Почему? Пока идёт выполнение ваших задач, что мешает пройтись по списку еще раз? (Кроме религиозных соображений)

Здравствуйте, _NN_, Вы писали:

_NN>Ну к примеру у меня LINQ выражение какое-нибудь.
И что вам мешает реализовать несколько интерфейсов?

_NN>Это если такая возможность есть.
_NN>Не каждый IEnumerable даст пройтись два раза без последствий.
Это уже кривые реализации. В IEnumerable есть который должен переходить в начало.
IEnumerable.Reset

Здравствуйте, kov_serg, Вы писали:

_>Здравствуйте, _NN_, Вы писали:

_NN>>Ну к примеру у меня LINQ выражение какое-нибудь.
_>И что вам мешает реализовать несколько интерфейсов?

Ну например у меня энумератор отправляет данные на сервер и ждёт ответа, а повторный проход даст другой результат.
А в руках у меня только IEnumerable.
Да что угодно может быть.

Здравствуйте, _NN_, Вы писали:


_>>И что вам мешает реализовать несколько интерфейсов?

_NN>Ну например у меня энумератор отправляет данные на сервер и ждёт ответа, а повторный проход даст другой результат.
Что мешает от сервера получить количество элементов?
_NN>А в руках у меня только IEnumerable.
Сделайте копию.
_NN>Да что угодно может быть.
Так и исключения можно кидать при переходе к следующему элементу.

https://youtu.be/uK7pDCYslDA?t=392

Здравствуйте, _NN_, Вы писали:

_NN>У IEnumerable enumerable нет Count, иначе не было бы вопроса.
Зависит от того, кто этот IEnumerable представляет. Для ICollection возьмет из Count
https://github.com/microsoft/referencesource/blob/master/System.Core/System/Linq/Enumerable.cs

public static int Count<TSource>(this IEnumerable<TSource> source) {
            if (source == null) throw Error.ArgumentNull("source");
            ICollection<TSource> collectionoft = source as ICollection<TSource>;
            if (collectionoft != null) return collectionoft.Count;
            ICollection collection = source as ICollection;
            if (collection != null) return collection.Count;
            int count = 0;
            using (IEnumerator<TSource> e = source.GetEnumerator()) {
                checked {
                    while (e.MoveNext()) count++;
                }
            }
            return count;
        }

Здравствуйте, _NN_, Вы писали:

_NN>Ну например у меня энумератор отправляет данные на сервер и ждёт ответа, а повторный проход даст другой результат.
_NN>А в руках у меня только IEnumerable.
_NN>Да что угодно может быть.

С такой постановкой исходный вопрос вообще не имеет значения. Делай хоть так, хоть эдак — на скорость не влияет. И Interlocked.Increment, и создание тасков вместе с последующим GC, в обычном случае настолько быстрее, чем запрос к серверу на каждый enumerable, что разницу нельзя будет заметить.

Здравствуйте, kov_serg, Вы писали:

_NN>>У IEnumerable enumerable нет Count, иначе не было бы вопроса.
_>Что мешает добавить в свой интерфейс с количеством элементов.
_>Вы же это список заполняли как-то.

Это абстракция IEnumerable. Количество элементов никому не известно на момент получения первых элементов. Иначе это был бы ICollection.

_NN>>А вызов Enumerable.Count() приведёт к двойному обходу перечисления, что тоже не подходит.
_>Почему? Пока идёт выполнение ваших задач, что мешает пройтись по списку еще раз? (Кроме религиозных соображений)

Начать с того, что это не список. Повторный проход по IEnumerable может вызвать повторный вызов SELECT * FROM, например. С совершенно иным результатом.

Всем спасибо за мысли и советы.
На данный момент проще привести всё заранее к массиву так как количество не превысит нескольких тысяч.
А вот создавать тысячи таксов это гораздо хуже.