AW: DorothyLocker and performance

Hi!

It _was_ noticeably slower. But it isn't any more - I just checked the
current CVS and it worked fine. Looks like the patch by Thomas did a =
lot for
performance, at least on my machine.

A few measures:

first activation of aggregator: 26 seconds with inspect.stack() and 6
seconds with inspect.stack(context=3D0)

second activation of aggregator: 30 seconds with inspect.stack() and 2
seconds with inspect.stack(context=3D0)

shutdown: over a minute with inspect.stack() and 5 seconds with
inspect.stack(context=3D0)

From the log it looks like that with inspect.stack() it just takes a =
bit
longer so that other threads try to fetch locks and don't get them and =
so
the system trashes and becomes unuseable - it outputs far less lockings =
with
inspect.stack(context=3D0). So the results might be highly different on =
faster
machines, as trashing is something that's dependend on machine =
performance,
os performance, memory usage and several other factors.

I made another patch: EventTool did still look for self.lock in =
shutdown
because of tools trying to log stuff on shutdown after the EventTool =
was
already down (and so had no lock attribute). I changed the if not =
self.lock
into a (hopefully) working if not hasattr(self, 'lock').

bye, Georg

-----Urspr=FCngliche Nachricht-----
Von: Garth T Kidd [mailto:garth-OnzZ1s1DREKDegMON/[email protected]]
Gesendet: Sonntag, 26. September 2004 14:31
An: 'Thomas Klaeger'; pyds-dev-iYtK5bfT9M//Ad8WF/[email protected]
Betreff: RE: [Pyds-dev] 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.=20

Regards,
Garth.=20

-----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


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