try/catch on dequeue is way slower than my own lock

[not_a_commie]

Using a synchronized Queue, I did some testing on catching the "queue
was empty on dequeue" exception vs. doing my own lock, checking for
empty, and then dequeuing. The try/catch method, though simpler in
code, was 100x slower than doing my own empty-check before dequeue.
That seems incredible to me that the try/catch handlers could be that
much slower than a lock and an empty check. It makes me want to go
through the codebase and rip out all the try-catch blocks that I
possibly can. Was it because I was running in the debugger? Would it
be better if I compiled in release mode?

 

[Chris Dunaway]

Using a synchronized Queue, I did some testing on catching the "queue
was empty on dequeue" exception vs. doing my own lock, checking for
empty, and then dequeuing. The try/catch method, though simpler in
code, was 100x slower than doing my own empty-check before dequeue.
That seems incredible to me that the try/catch handlers could be that
much slower than a lock and an empty check. It makes me want to go
through the codebase and rip out all the try-catch blocks that I
possibly can. Was it because I was running in the debugger? Would it
be better if I compiled in release mode?

Without seeing some code it's difficult to say. IMO, if you can check
whether or not the queue is empty, then do so rather than relying on
the exception because exceptions are slower.

Can you show a short but complete program which illustrates your
problem?

Chris

 

[William Stacey [C# MVP]]

IMO, you can't reliably check for empty condition anyway unless you take the
lock first and do your check. You need the lock anyway if there is item, so
take the lock being optimistic there is some data. You could use Count as a
hint for non-critical/non-atomic operations, but don't rely on it unless
your inside the lock. Couple ways to go on empty. 1) you can throw error.
2) you can return a default(T) and let caller deside what to do. 3) you can
block till some item appears. It depends on your collection and what you
want your api to do. I normally prefer a Tryxxx method if possible so I can
avoid the error condition and get explicit condition if queue is really
empty and not have to guess on what default(T) means.

--
William Stacey [C# MVP]
PCR concurrency library: www.codeplex.com/pcr
PSH Scripts Project www.codeplex.com/psobject


| Using a synchronized Queue, I did some testing on catching the "queue
| was empty on dequeue" exception vs. doing my own lock, checking for
| empty, and then dequeuing. The try/catch method, though simpler in
| code, was 100x slower than doing my own empty-check before dequeue.
| That seems incredible to me that the try/catch handlers could be that
| much slower than a lock and an empty check. It makes me want to go
| through the codebase and rip out all the try-catch blocks that I
| possibly can. Was it because I was running in the debugger? Would it
| be better if I compiled in release mode?
|

 

[Jon Skeet [C# MVP]]

Using a synchronized Queue, I did some testing on catching the "queue
was empty on dequeue" exception vs. doing my own lock, checking for
empty, and then dequeuing. The try/catch method, though simpler in
code, was 100x slower than doing my own empty-check before dequeue.
That seems incredible to me that the try/catch handlers could be that
much slower than a lock and an empty check. It makes me want to go
through the codebase and rip out all the try-catch blocks that I
possibly can. Was it because I was running in the debugger? Would it
be better if I compiled in release mode?

If you're running in a debugger, that will indeed make exceptions
significantly slower than not in a debugger.

However, this is an abuse of exceptions - you can easily check for the
queue being empty, so don't just "hit and hope".

You should indeed go through your code if you have a lot of try/catch
blocks - but more for design reasons than performance. Generally you
should have far more try/finally blocks (usually in the form of using
statements) than try/catch blocks. If you're regularly doing try/catch
for something which you can test beforehand, that's a design flaw IMO.

 

[not_a_commie]

Can you show a short but complete program which illustrates your

problem?

Here she be. I would also appreciate it if you could confirm that I'm
doing the locking correctly. I need the AddItem function to run in one
thread and GetPriorityItem function to run in a different thread. It
seems that running outside the debugger is significantly faster at
exceptions, but still way slower than otherwise. I'm still entirely
astounded at how drastic the difference is between the two.

using System;
using System.Collections.Generic;
using System.Text;
using System.Collections;
using System.Diagnostics;

namespace QueueDemoApp
{
class Program
{
class LeveledQueue
{
Queue[] queues;
public LeveledQueue(uint numPriorities)
{
queues = new Queue[numPriorities];
for(int i = 0; i < numPriorities; i++)
queues = Queue.Synchronized(new Queue());
}
public void AddItem(uint priority, object item)
{
if (priority < queues.Length)
queues[priority].Enqueue(item);
}
public object GetHighestPriorityItemFast()
{
for (int i = queues.Length - 1; i >= 0; i--)
{
Queue q = queues;
lock (q.SyncRoot) // same lock as the Dequeue/
Enqueue use?
{
if (q.Count > 0)
return q.Dequeue();
}
}
return null;
}
public object GetHighestPriorityItemSlow()
{
for (int i = queues.Length - 1; i >= 0; i--)
{
Queue q = queues;
try
{
object ret = q.Dequeue();
return ret;
}
catch (InvalidOperationException) { }
}
return null;
}
}
static void Main(string[] args)
{
LeveledQueue lq = new LeveledQueue(16);
// worst case will be when they have no data

Stopwatch sw = new Stopwatch();
sw.Start();
for (int i = 0; i < 4000; i++)
{
object obj = lq.GetHighestPriorityItemFast();
}
sw.Stop();
Console.WriteLine("Fast call used {0} seconds for 4k",
sw.Elapsed.TotalSeconds);
sw.Reset();
sw.Start();
for (int i = 0; i < 4000; i++)
{
object obj = lq.GetHighestPriorityItemSlow();
}
sw.Stop();
Console.WriteLine("Slow call used {0} seconds for 4k",
sw.Elapsed.TotalSeconds);
}
}
}

 

[Jon Skeet [C# MVP]]

Here she be. I would also appreciate it if you could confirm that I'm
doing the locking correctly. I need the AddItem function to run in one
thread and GetPriorityItem function to run in a different thread. It
seems that running outside the debugger is significantly faster at
exceptions, but still way slower than otherwise. I'm still entirely
astounded at how drastic the difference is between the two.

Well, the locking is correct - and is the right way to go. Exceptions
aren't meant to be used the way you're using them. They're meant to be
used for *exceptional* situations. If the logic of your program should
make it an error for the queue to be empty, you should try to dequeue
and *not* catch the exception there, but much higher up. If, however,
the logic of your program doesn't try to stop the queue from being
empty, then you shouldn't use an exception at all. Your "fast" version
is exactly the right way of doing things.

Admittedly I'd just do:

return q.Count > 0 ? q.Dequeue() : null;

but the effect is the same.


Any time you want to catch an exception and just swallow it, you should
re-examine your design. It *may* be appropriate (the situation may be
forced on you by a library you're using, for instance) but usually it's
a bad sign.