Насколько масштабируемый Система. Поточная обработка. Таймер?
Еще одна вариация Ddi's :
function* iter(it) {
yield* it;
}
function* zip(...its) {
its = its.map(iter);
while (true) {
let rs = its.map(it => it.next());
if (rs.some(r => r.done))
return;
yield rs.map(r => r.value);
}
}
for (let r of zip([1,2,3], [4,5,6,7], [8,9,0,11,22]))
console.log(r.join())
// the only change for "longest" is some -> every
function* zipLongest(...its) {
its = its.map(iter);
while (true) {
let rs = its.map(it => it.next());
if (rs.every(r => r.done))
return;
yield rs.map(r => r.value);
}
}
for (let r of zipLongest([1,2,3], [4,5,6,7], [8,9,0,11,22]))
console.log(r.join()) И вот как написать py classic zip(*[iter(a)]*n) :
triples = [...zip(...Array(3).fill(iter(a)))]
4 ответа
Я говорю это в ответ на большое количество вопросов: не забывайте, что (управляемый) исходный код к платформе доступен. Можно использовать этот инструмент для получения всего этого: http://www.codeplex.com/NetMassDownloader
, К сожалению, в этом конкретном случае, большой реализации находится в собственном коде, таким образом, Вы не добираетесь для рассмотрения его...
Они определенно используют потоки пула, а не поток на таймер, все же.
стандартный способ реализовать большой набор таймеров (который является, как ядро делает это внутренне, и я подозревал бы, косвенно, как Ваш большой набор Таймеров заканчивается), должен вести список, отсортированный по времени до истечения - таким образом, система только когда-либо должна волноваться о проверке следующего таймера, который собирается истечь, не целый список.
Примерно, это дает O (зарегистрируйте n) для запуска таймера и O (1) для обработки рабочих таймеров.
Редактирование: Просто взгляд в книге Jeff Richter. Он говорит (Поточной обработки. Таймер), что это использует единственный поток для всех Объектов - таймеров, этот поток, знает, когда следующий таймер (т.е. как выше) должен и называет ThreadPool. QueueUserWorkItem для обратных вызовов как соответствующие. Это имеет эффект, что, если Вы не заканчиваете обслуживать один обратный вызов на таймере, прежде чем следующее должно, что Ваш обратный вызов повторно вступит на другом потоке пула. Так, таким образом, я сомневаюсь, что Вы будете видеть большую проблему с наличием большого количества таймеров, но Вы могли бы перенести исчерпание пула потоков, если большие количества их стреляют в тот же таймер, и/или их обратные вызовы являются медленным выполнением.
Я думаю, что Вы могли бы хотеть заново продумать свой дизайн (то есть, если Вы управляете дизайном сами). При использовании такого количества таймеров, что это - на самом деле беспокойство о Вас, существует ясно некоторый потенциал для консолидации там.
Вот хорошая статья от MSDN Magazine от несколько лет назад, который сравнивает три доступных класса таймера и дает некоторое понимание их реализаций:
Консолидируют их. Создайте сервис таймера и попросите у этого таймеров. Это должно будет только сохранить 1 активный таймер (для следующего должного вызова)...
Для этого, чтобы быть улучшением, законченным просто создание большой Поточной обработки. Объекты - таймеры, необходимо предположить, что это не точно что Поточная обработка. Таймер уже делает внутренне. Мне было бы интересно знать, как Вы пришли к тому заключению (я не демонтировал собственные биты платформы, таким образом, Вы могли быть правы).
^^ как DannySmurf говорит: Консолидируйте их. Создайте сервис таймера и попросите у этого таймеров. Это должно будет только сохранить 1 активный таймер (для следующего должного вызова) и история всех запросов таймера и повторно вычислить это на AddTimer () / RemoveTimer ().