Jru*_*rud 5 .net theory performance timer concept
我计划在其中开发一个包含数万个对象的系统,每个对象最多可以有42个(但更可能是大约4或5个),它们可能会定期执行单独的操作.我还计划编写代码来停用定时器,直到对象开始使用.空闲时,对象每个只需要1个计时器,但是当激活时,其他计时器将立即启动.起初,对象的数量很少,可能只有几百个,但我预计它会成倍增长,并在几个月内开始达到成千上万.
因此,我非常担心我将为计时器和这些对象编写的代码的效率.我可以在三个级别编写此应用程序,这将成功执行所需的任务.此外,我计划在四核服务器上运行此系统,因此我希望尽可能使用多线程.
为此,我决定使用System.Timers.Timer类的时候触发一个新的线程为每个经过的事件.
这些是我正在考虑的3个级别:
一个单定时器操作整个应用程序,它通过每个迭代对象,检查,看看是否有任何其他动作需要被解雇,如果是这样,运行它们,然后移动到下一个.
多层计时器,其中每个对象都有一个主计时器,用于检查对象可能需要执行的所有功能,运行任何准备好的计时器,然后将下一个计时器间隔设置为下一个所需的操作时间.
递归级定时器,其中每个对象中的每个动作都有它自己的定时器将被触发,然后设置为下一次将可运行.
选项1的问题在于,如此多的对象和动作,以这种方式经过的一个单一计时器可能会运行大约20多秒(当它执行几百万行循环代码时),这应该每1秒滴答一次.如果对象未保持同步,则系统可能无法正常工作.
选项2的问题在于它比选项3更难写,但不是很多,它也意味着可能在系统上运行10,000个可能的定时器(每个对象一个),创建和销毁每个对象的线程过去就像没有人的生意(我不确定这是否是一个问题).每个定时器将不得不在这种情况下,每秒至少一次火,也许几百行代码(在极端情况下可达也许一千)上运行.
选项3的问题在于可能引入系统的大量定时器.我说的是平均10,000多个计时器,可能同时运行近100,000个计时器.每个过去的事件可能只需要运行50行或更少的代码行,这使得它们非常短.经过事件会对在另一个极端,五分钟一百分之一秒之间的延迟,平均可能是1秒左右.
我精通Visual Basic .NET,并计划在其中编写它,但我也可以恢复到我的高中时代,并尝试用C++编写这个以提高效率,如果它会产生很大的不同(请让我知道你是否有任何语言代码效率的来源).还在玩集群Linux服务器而不是我的四核Windows服务器上运行它的概念,但我不确定我是否可以让我的任何.NET应用程序在这样的Linux集群上运行(会喜欢任何信息)在那上面).
这个主题的主要问题是:
我是否使用选项1,2或3,为什么？
〜考虑评论后编辑〜
所以第四个选项涉及带有自旋锁的定时器轮.这是一个工作班:
Public Class Job
Private dFireTime As DateTime
Private objF As CrossAppDomainDelegate
Private objParams() As Object
Public Sub New(ByVal Func As CrossAppDomainDelegate, ByVal Params() As Object, ByVal FireTime As DateTime)
objF = Func
dFireTime = FireTime
objParams = Params
End Sub
Public ReadOnly Property FireTime()
Get
Return dFireTime
End Get
End Property
Public ReadOnly Property Func() As CrossAppDomainDelegate
Get
Return objF
End Get
End Property
Public ReadOnly Property Params() As Object()
Get
Return objParams
End Get
End Property
End Class
然后是主循环实现:
Private Tasks As LinkedList(Of Job)
Private Sub RunTasks()
While True
Dim CurrentTime as DateTime = Datetime.Now
If Not Tasks.Count = 0 AndAlso Tasks(0).FireTime > CurrentTime Then
Dim T As Job = Tasks(0)
Tasks.RemoveFirst()
T.Func.Invoke()
Else
Dim MillisecondDif As Double
MillisecondDif = Tasks(0).FireTime.Subtract(CurrentTime).Milliseconds
If MillisecondDif > 30 Then
Threading.Thread.Sleep(MillisecondDif)
End If
End If
End While
End Sub
我说得对吗？
〜编辑2~
将"任务"一词改为"工作",以便人们可以停止抱怨;)
〜编辑3~
添加了跟踪时间的变量,并确保在需要时发生spinloops
编辑:我记得有趣的访谈值得一看:Arun Kishan:Windows 7内部 - 告别Windows内核调度程序锁
正如@Steven Sudit所说,我再次发出警告:仅将其用作演示计时器轮的工作方式以及实施时必须关注的一些任务.不作为参考实现.在现实世界中,您必须编写更复杂的逻辑来考虑可用资源,调度逻辑等.
Steven Sudit在这里提出了一些好处(详见阅读帖子评论):
1)选择正确的结构来保存你的工作清单(通常取决于):
SortedList <>(或SortedDictionary <>)在内存消耗和索引方面很好,但必须实现同步访问
ConcurrentQueue <>将帮助您避免锁定,但您必须实现排序.它也非常有效
LinkedList <>在插入和检索方面很好(无论如何我们只需要头部)但需要同步访问(通过无锁可以很容易地实现)而且存储效率不高,因为它存储了两个引用(prev/next).但是当你拥有数百万个工作岗位时,这会成为一个问题,因此所有这些工作都需要大量的内存.
但:
我完全同意@Steven:
没关系:这些都不合适.正确的答案是使用常规队列并自己维护其顺序,因为我们通常只需要从头部或尾部访问它.
通常,我建议使用库中功能最全的集合,但这不适用于此,因为这是系统级代码.我们需要从头开始或在功能较少的集合之上推出自己的产品
2)为了简化同时作业的处理逻辑,您可以将委托列表(例如,通过ConcurrentQueue使其无锁)添加到原始Job类中,这样当您需要同时执行另一个作业时,您只需添加另一个委托即可启动.
@Steven:
如果实际上同时安排了两个任务(无论是实际还是有效),这是一个正常情况,不需要使我们的数据结构复杂化.换句话说,我们不需要对同时工作进行分组,因此我们必须遍历两个不同的集合; 我们可以让它们相邻
3)启动/停止调度程序不是那么直接,因此可能导致错误.相反,您可以在使用超时时等待事件.
@Steven:
这样,它将在下一个作业准备就绪时或在头部之前插入新作业时唤醒.在后一种情况下,它可能需要现在运行它或设置不同的等待.如果在同一时刻出现100个工作,我们能做的最好的事情就是将它们全部排队.
如果我们需要提供优先级,那就是优先级调度队列和生产者/消费者关系中的多个池的工作,但它仍然不能证明启动/停止调度程序的合理性.调度程序应始终打开,在单个循环中运行,有时会放弃核心
4)关于使用刻度:
@Steven:
坚持一种类型的滴答很好,但混合和匹配变得很难看,特别是因为它依赖于硬件.我确定滴答声会比毫秒略快,因为它存储前者并且必须除以常数才能得到后者.这项行动是否成本高昂是另一回事,但我可以使用蜱来避免风险.
我的想法:
另一个好处,我同意你的看法.但有时按常数划分会变得昂贵,并且它看起来不会那么快.但是当我们谈论10万个DateTimes并不重要时,你是对的,谢谢你指出.
5)"管理资源":
@Steven:
我试图强调的问题是对GetAvailableThreads的调用既昂贵又天真; 在你甚至可以使用它之前,答案已经过时了.如果我们真的想要跟踪,我们可以通过从使用Interlocked.Increment/Decrement的包装器调用作业来获取初始值并保持运行计数.即使这样,它也假定程序的其余部分没有使用线程池.如果我们真的想要精确控制,那么这里正确的答案就是推出我们自己的线程池
我绝对同意调用GetAvailableThreads是一种天真的方法,通过CorGetAvailableThreads来监控可用资源并不那么昂贵.我想要进行管理,需要管理资源,似乎选择了不好的例子.
通过源代码示例中提供的任何方式,不得将其视为监视可用资源的正确方法.我只是想证明你必须考虑它.通过编码没有那么好的代码片段作为例子.
6)使用Interlocked.CompareExchange:
@Steven:
不,这不是一种常见的模式.最常见的模式是暂时锁定.不太常见的是将变量标记为volatile.更不常见的是使用VolatileRead或MemoryBarrier.使用Interlocked.CompareExchange这种方式是模糊的,即使Richter这样做.使用它而没有解释性注释绝对可以保证混淆,因为"比较"一词意味着我们正在进行比较,而事实上我们并非如此.
你是对的,我必须指出它的用法.
using System;
using System.Threading;
// Job.cs
// WARNING! Your jobs (tasks) have to be ASYNCHRONOUS or at least really short-living
// else it will ruin whole design and ThreadPool usage due to potentially run out of available worker threads in heavy concurrency
// BTW, amount of worker threads != amount of jobs scheduled via ThreadPool
// job may waits for any IO (via async call to Begin/End) at some point
// and so free its worker thread to another waiting runner
// If you can't achieve this requirements then just use usual Thread class
// but you will lose all ThreadPool's advantages and will get noticeable overhead
// Read http://msdn.microsoft.com/en-us/magazine/cc164139.aspx for some details
// I named class "Job" instead of "Task" to avoid confusion with .NET 4 Task
public class Job
{
public DateTime FireTime { get; private set; }
public WaitCallback DoAction { get; private set; }
public object Param { get; private set; }
// Please use UTC datetimes to avoid different timezones problem
// Also consider to _never_ use DateTime.Now in repeat tasks because it significantly slower
// than DateTime.UtcNow (due to using TimeZone and converting time according to it)
// Here we always work with with UTC
// It will save you a lot of time when your project will get jobs (tasks) posted from different timezones
public static Job At(DateTime fireTime, WaitCallback doAction, object param = null)
{
return new Job {FireTime = fireTime.ToUniversalTime(), DoAction = doAction, Param = param};
}
public override string ToString()
{
return string.Format("{0}({1}) at {2}", DoAction != null ? DoAction.Method.Name : string.Empty, Param,
FireTime.ToLocalTime().ToString("o"));
}
}
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Threading;
// Dispatcher.cs
// Take a look at System.Runtime IOThreadTimer.cs and IOThreadScheduler.cs
// in Microsoft Reference Source, its interesting reading
public class Dispatcher
{
// You need sorted tasks by fire time. I use Ticks as a key to gain some speed improvements during checks
// There are maybe more than one task in same time
private readonly SortedList<long, List<Job>> _jobs;
// Synchronization object to access _jobs (and _timer) and make it thread-safe
// See comment in ScheduleJob about locking
private readonly object _syncRoot;
// Queue (RunJobs method) is running flag
private int _queueRun;
// Flag to prevent pollute ThreadPool with many times scheduled JobsRun
private int _jobsRunQueuedInThreadPool;
// I'll use Stopwatch to measure elapsed interval. It is wrapper around QueryPerformanceCounter
// It does not consume any additional resources from OS to count
// Used to check how many OS ticks (not DateTime.Ticks!) elapsed already
private readonly Stopwatch _curTime;
// Scheduler start time. It used to build time delta for job
private readonly long _startTime;
// System.Threading.Timer to schedule next active time
// You have to implement syncronized access as it not thread-safe
// http://msdn.microsoft.com/en-us/magazine/cc164015.aspx
private readonly Timer _timer;
// Minimum timer increment to schedule next call via timer instead ThreadPool
// Read http://www.microsoft.com/whdc/system/pnppwr/powermgmt/Timer-Resolution.mspx
// By default it around 15 ms
// If you want to know it exactly use GetSystemTimeAdjustment via Interop ( http://msdn.microsoft.com/en-us/library/ms724394(VS.85).aspx )
// You want TimeIncrement parameter from there
private const long MinIncrement = 15 * TimeSpan.TicksPerMillisecond;
// Maximum scheduled jobs allowed per queue run (specify your own suitable value!)
// Scheduler will add to ThreadPool queue (and hence count them as processed) no more than this constant
// This is balance between how quick job will be scheduled after it time elapsed in one side, and
// how long JobsList will be blocked and RunJobs owns its thread from ThreadPool
private const int MaxJobsToSchedulePerCheck = 10;
// Queue length
public int Length
{
get
{
lock (_syncRoot)
{
return _jobs.Count;
}
}
}
public Dispatcher()
{
_syncRoot = new object();
_timer = new Timer(RunJobs);
_startTime = DateTime.UtcNow.Ticks;
_curTime = Stopwatch.StartNew();
_jobs = new SortedList<long, List<Job>>();
}
// Is dispatcher still working
// Warning! Queue ends its work when no more jobs to schedule but started jobs can be still working
public bool IsWorking()
{
return Interlocked.CompareExchange(ref _queueRun, 0, 0) == 1;
}
// Just handy method to get current jobs list
public IEnumerable<Job> GetJobs()
{
lock (_syncRoot)
{
// We copy original values and return as read-only collection (thread-safety reasons)
return _jobs.Values.SelectMany(list => list).ToList().AsReadOnly();
}
}
// Add job to scheduler queue (schedule it)
public void ScheduleJob(Job job)
{
// WARNING! This will introduce bottleneck if you have heavy concurrency.
// You have to implement lock-free solution to avoid botleneck but this is another complex topic.
// Also you can avoid lock by using Jeffrey Richter's ReaderWriterGateLock (http://msdn.microsoft.com/en-us/magazine/cc163532.aspx)
// But it can introduce significant delay under heavy load (due to nature of ThreadPool)
// I recommend to implement or reuse suitable lock-free algorithm.
// It will be best solution in heavy concurrency (if you have to schedule large enough job count per second)
// otherwise lock or maybe ReaderWriterLockSlim is cheap enough
lock (_syncRoot)
{
// We'll shift start time to quick check when it pasts our _curTime
var shiftedTime = job.FireTime.Ticks - _startTime;
List<Job> jobs;
if (!_jobs.TryGetValue(shiftedTime, out jobs))
{
jobs = new List<Job> {job};
_jobs.Add(shiftedTime, jobs);
}
else jobs.Add(job);
if (Interlocked.CompareExchange(ref _queueRun, 1, 0) == 0)
{
// Queue not run, schedule start
Interlocked.CompareExchange(ref _jobsRunQueuedInThreadPool, 1, 0);
ThreadPool.QueueUserWorkItem(RunJobs);
}
else
{
// else queue already up and running but maybe we need to ajust start time
// See detailed comment in RunJobs
long firetime = _jobs.Keys[0];
long delta = firetime - _curTime.Elapsed.Ticks;
if (delta < MinIncrement)
{
if (Interlocked.CompareExchange(ref _jobsRunQueuedInThreadPool, 1, 0) == 0)
{
_timer.Change(Timeout.Infinite, Timeout.Infinite);
ThreadPool.QueueUserWorkItem(RunJobs);
}
}
else
{
Console.WriteLine("DEBUG: Wake up time changed. Next event in {0}", TimeSpan.FromTicks(delta));
_timer.Change(delta/TimeSpan.TicksPerMillisecond, Timeout.Infinite);
}
}
}
}
// Job runner
private void RunJobs(object state)
{
// Warning! Here I block list until entire process done,
// maybe better will use ReadWriterLockSlim or somewhat (e.g. lock-free)
// as usually "it depends..."
// Here processing is really fast (a few operation only) so until you have to schedule many jobs per seconds it does not matter
lock (_syncRoot)
{
// We ready to rerun RunJobs if needed
Interlocked.CompareExchange(ref _jobsRunQueuedInThreadPool, 0, 1);
int availWorkerThreads;
int availCompletionPortThreads;
// Current thread stats
ThreadPool.GetAvailableThreads(out availWorkerThreads, out availCompletionPortThreads);
// You can check max thread limits by
// ThreadPool.GetMaxThreads(out maxWorkerThreads, out maxCompletionPortThreads);
int jobsAdded = 0;
while (jobsAdded < MaxJobsToSchedulePerCheck && availWorkerThreads > MaxJobsToSchedulePerCheck + 1 && _jobs.Count > 0)
{
// SortedList<> implemented as two arrays for keys and values so indexing on key/value will be fast
// First element
List<Job> curJobs = _jobs.Values[0];
long firetime = _jobs.Keys[0];
// WARNING! Stopwatch ticks are different from DateTime.Ticks
// so we use _curTime.Elapsed.Ticks instead of _curTime.ElapsedTicks
// Each tick in the DateTime.Ticks value represents one 100-nanosecond interval.
// Each tick in the ElapsedTicks value represents the time interval equal to 1 second divided by the Frequency.
if (_curTime.Elapsed.Ticks <= firetime) break;
while (curJobs.Count > 0 && jobsAdded < MaxJobsToSchedulePerCheck && availWorkerThreads > MaxJobsToSchedulePerCheck + 1)
{
var job = curJobs[0];
// Time elapsed and we ready to start job
if (job.DoAction != null)
{
// Schedule new run
// I strongly recommend to look at new .NET 4 Task class because it give superior solution for managing Tasks
// e.g. cancel run, exception handling, continuation, etc
ThreadPool.QueueUserWorkItem(job.DoAction, job);
++jobsAdded;
// It may seems that we can just decrease availWorkerThreads by 1
// but don't forget about started jobs they can also consume ThreadPool's threads
ThreadPool.GetAvailableThreads(out availWorkerThreads, out availCompletionPortThreads);
}
// Remove job from list of simultaneous jobs
curJobs.Remove(job);
}
// Remove whole list if its empty
if (curJobs.Count < 1) _jobs.RemoveAt(0);
}
if (_jobs.Count > 0)
{
long firetime = _jobs.Keys[0];
// Time to next event
long delta = firetime - _curTime.Elapsed.Ticks;
if (delta < MinIncrement)
{
// Schedule next queue check via ThreadPool (immediately)
// It may seems we start to consume all resouces when we run out of available threads (due to "infinite" reschdule)
// because we pass thru our while loop and just reschedule RunJobs
// but this is not right because before RunJobs will be started again
// all other thread will advance a bit and maybe even complete its task
// so it safe just reschedule RunJobs and hence wait when we get some resources
if (Interlocked.CompareExchange(ref _jobsRunQueuedInThreadPool, 1, 0) == 0)
{
_timer.Change(Timeout.Infinite, Timeout.Infinite);
ThreadPool.QueueUserWorkItem(RunJobs);
}
}
else // Schedule next check via timer callback
{
Console.WriteLine("DEBUG: Next event in {0}", TimeSpan.FromTicks(delta)); // just some debug output
_timer.Change(delta / TimeSpan.TicksPerMillisecond, Timeout.Infinite);
}
}
else // Shutdown the queue, no more jobs
{
Console.WriteLine("DEBUG: Queue ends");
Interlocked.CompareExchange(ref _queueRun, 0, 1);
}
}
}
}
快速使用示例:
// Test job worker
static void SomeJob(object param)
{
var job = param as Job;
if (job == null) return;
Console.WriteLine("Job started: {0}, [scheduled to: {1}, param: {2}]", DateTime.Now.ToString("o"),
job.FireTime.ToLocalTime().ToString("o"), job.Param);
}
static void Main(string[] args)
{
var curTime = DateTime.UtcNow;
Console.WriteLine("Current time: {0}", curTime.ToLocalTime().ToString("o"));
Console.WriteLine();
var dispatcher = new Dispatcher();
// Schedule +10 seconds to future
dispatcher.ScheduleJob(Job.At(curTime + TimeSpan.FromSeconds(10), SomeJob, "+10 sec:1"));
dispatcher.ScheduleJob(Job.At(curTime + TimeSpan.FromSeconds(10), SomeJob, "+10 sec:2"));
// Starts almost immediately
dispatcher.ScheduleJob(Job.At(curTime - TimeSpan.FromMinutes(1), SomeJob, "past"));
// And last job to test
dispatcher.ScheduleJob(Job.At(curTime + TimeSpan.FromSeconds(25), SomeJob, "+25 sec"));
Console.WriteLine("Queue length: {0}, {1}", dispatcher.Length, dispatcher.IsWorking()? "working": "done");
Console.WriteLine();
foreach (var job in dispatcher.GetJobs()) Console.WriteLine(job);
Console.WriteLine();
Console.ReadLine();
Console.WriteLine(dispatcher.IsWorking()?"Dispatcher still working": "No more jobs in queue");
Console.WriteLine();
foreach (var job in dispatcher.GetJobs()) Console.WriteLine(job);
Console.ReadLine();
}
希望它会有所帮助.
@Steven Sudit point me some issues, so here I try to give my vision.
1) I wouldn't recommend using SortedList here, or anywhere else, as it's an obsolete .NET 1.1 class
SortedList<> by any means is not obsolete. It still exists in .NET 4.0 and introduced in .NET 2.0 when generics was introduced into language. I can't see any point to remove it from .NET.
But real question here I trying to answer: What data structure can store values in sorted order and will be efficient in storing and indexing. There are two suitable ready to use data structures: SortedDictionary<> and SortedList<>. Here some info about how to choose. I just don't want waste implementation with my own code and hide main algorithm. Here I can implement priority-array or something other but it takes more lines to code. I don't see any reason do not use SortedList<> here...
BTW, I can't understand why you not recommend it? What are reasons?
2) In general, there's no need to complicate the code with special cases for simultaneous events.
When @Jrud says he probably will have numerous task to schedule I think it they may have heavy concurrency, so I demonstrate how to solve it. But my point: even if you have low concurrency you stil have chance to get events in same time. Also this is easy possible in multithreaded evironment or when there are many sources want to schedule jobs.
Interlocked functions not so complicated, cheap and since .NET 4.0 inlined so there are no problem to add guard in such situation.
3) The IsWorking method should just use a memory barrier and then read the value directly.
Im not so sure here that you are right. I would recommend to read two nice articles: Part 4: Advanced Threading of Threading in C# by Joseph Albahari and How Do Locks Lock? by Jeff Moser. And of cause Chapter 28 (Primitive Thread Synchronization Constructs) of CLR via C# (3rd edition) by Jeffrey Richter.
Here some qoute:
The MemoryBarrier method doesn’t access memory but it forces any earlier programorder loads and stores to be completed before the call to MemoryBarrier. And it also forces any later program-order loads and stores to be completed after the call to MemoryBarrier. MemoryBarrier is much less useful than the other two methods
Important I know that this can be very confusing, so let me summarize it as a simple rule: When threads are communicating with each other via shared memory, write the last value by calling VolatileWrite and read the first value by calling VolatileRead.
I would also recommend: Intel® 64 and IA-32 Architectures Software Developer's Manuals if you care about it seriously.
So I don't use VolatileRead/VolatileWrite in my code neither volatile keyword, I don't think Thread.MemoryBarrier will be better here. Maybe you can point me what I miss? Some articles or in-depth discussion?
4) The GetJobs method looks like it could lock for an extended period. Is it necessary?
First of all its just handy method, sometime it is necessary to get all tasks in queue at least for debugging.
But you are not right. As I mentioned in code comments SortedList<> implemented as two arrays you can check this by Reference Source or just by viewing in Reflector. Here some comments from reference source:
// A sorted list internally maintains two arrays that store the keys and
// values of the entries.
I got from .NET 4.0 but it not changed much since 2-3.5
So my code:
_jobs.Values.SelectMany(list => list).ToList().AsReadOnly();
involve following:
so consequently we have just flatten read-only list of references to Job's objects. It very fast even you have millions of task. Try to measure yourself.
Any way I added it to show what happens during execution cycle (for debug purposes) but I think it can be useful.
5) A lock-free queue is available in .NET 4.0.
I would recommend to read Patterns of parallel programming by Stephen Toub and Thread-safe Collections in .NET Framework 4 and Their Performance Characteristics, also here many interesting articles.
So I quote:
ConcurrentQueue(T) is a data structure in .NET Framework 4 that provides thread-safe access to FIFO (First-In First-Out) ordered elements. Under the hood, ConcurrentQueue(T) is implemented using a list of small arrays and lock-free operations on the head and tail arrays, hence it is quite different than Queue(T) which is backed by an array and relies on the external use of monitors to provide synchronization. ConcurrentQueue(T) is certainly more safe and convenient than manual locking of a Queue(T) but some experimentation is required to determine the relative performance of the two schemes. In the remainder of this section, we will refer to a manually locked Queue(T) as a self-contained type called SynchronizedQueue(T).
It don't have any methods to maintain ordered queue. Neither any of new thread-safe collection, they all maintain unordered collection. But reading original @Jrud description I think we have to maintain ordered list of time when task need to be fired. Am I wrong?
6) I wouldn't bother starting and stopping the dispatcher; just let it sleep until the next job
Do you know good way to make sleep ThreadPool's thread? How you will implement it?
I think dispatcher goes "sleep" when he does not process any task and schedule job wake-up it. Anyway there are no special processing to put it sleep or wake up so in my thoughts this process equals "sleep".
If you told that I should just reschedule RunJobs via ThreadPool when no jobs available when you are wrong it will eat too many resources and can impact started jobs. Try yourself. Why to do unnecessary job when we can easily avoid it.
7) Rather than worrying about different kinds of ticks, you could just stick to milliseconds.
You are not right. Either you stick to ticks or you don't care about it entirely. Check DateTime implementation, each access to milliseconds property involve converting internal representaion (in ticks) to ms including division. This can hurt performance on old (Pentium class) compulters (I measure it myself and you can too).
In general I will agree with you. We don't care about representation here because it does not give us noticeable performance boost.
It just my habbit. I process billions of DateTime in recent project so coded accordingly to it. In my project there are noticeable difference between processing by ticks and by other components of DateTime.
8) The attempt to keep track of available threads does not seem likely to be effective
I just want to demonstrate you have to care about it. In real world you have to implement far from my straightful logic of scheduling and monitoring resources.
I want to demonstrate timer wheel algorithm and point to some problem that author have to think when implement it.
You are absolutely right I have to warn about it. I thought "quickly ptototype" would be enough. My solution in any means can't be used in production.
| 归档时间： |
|
| 查看次数： |
2370 次 |
| 最近记录： |