RE: DorothyLocker and performance

Thing is, there just isn't that much locking going on that a single-digit
thousands of a second per lock overhead is going to make that much of a
difference. Make either DorothyRLock or Rlock verbose and you'll see what I
mean. Maybe it's just the way we use the language down here, but "horribly
slow" to me says the delay should be at least noticeable to the human eye.
:)

In any case, DorothyRLock was intended specifically for debugging deadlocks
and dropped acquires or releases, all three of which I've run into with my
tool development which I tend to do in quite large batches. If you don't use
it because you don't need it, my feelings won't be hurt. 

Regards,
Garth. 

-----Original Message-----
From: pyds-dev-admin-iYtK5bfT9M//Ad8WF/[email protected]
[mailto:pyds-dev-admin-iYtK5bfT9M//Ad8WF/[email protected]] On Behalf Of Thomas Klaeger
Sent: Sunday, 26 September 2004 6:37 PM
To: pyds-dev-iYtK5bfT9M//Ad8WF/[email protected]
Subject: [Pyds-dev] DorothyLocker and performance

I did some preliminary performance measurements, comparing
DorothyLocker.DorothyRLock and threading.RLock. I was running the tests on
Win2K, on a slightly loaded machine with PIII 1GHz and 512MB RAM.

RLock create: 22 us
RLock acquire: 13-14 us
RLock release: 12 us
RLock second acquire: 9 us

DorothyRLock create: 32 us
DorothyRLock acquire: 1720-1760 us
DorothyRLock release: 1730 us
DorothyRLock second acquire: 2230 us

From these numbers it can be clearly seen that DorothyLocker has some great
performance impact!

So I would recommend DorothyLocker during testruns and after bigger changes
to the codebase, but not on a production system.

Regards, Thomas

_______________________________________________
Pyds-dev mailing list
Pyds-dev-iYtK5bfT9M//Ad8WF/[email protected]
http://www.westfalen.de/cgi-bin/mailman/listinfo/pyds-dev