Solving the Problem with Events: Weak Event Handlers

home
c#
view story

23 Kicks

Solving the Problem with Events: Weak Event Handlers(diditwith.net)

submitted by cls2deg(1535) 5 years, 2 months ago

One of the greatest frustration of working with delegates and events is that they can potentially cause memory leaks if they aren't unhooked. In this article, we will solve this problem in a variety of ways to get the best performance, memory use and syntax.

2 comments |category: C# |Views: 480
Tweet

tags: Delegates EventHandlers Generics Events another

Everyones tags:

Your Tags:

Please login or signup.

Add a live kick counter to your blog >> liveImage

You can even customize the image by choosing your own colors, and then clicking the button below to update the preview and the html code:

"Kick It" text
"Kick It" background
kick count text
kick count background
border

Simply copy and paste this HTML into your blog post.

Users who kicked this story:

alexpi(5) -

tom103(161) -

maltezefalkon(0) -

oazabir(1805)

More who kicked this story...

Comments:

posted by yesthatmcgurk(4063) 5 years, 2 months ago 0

Article is a better resource for the inner workings of the CLR and GC than for preventing event-related memory leaks.

posted by markell(5) 4 years, 3 months ago 0

Hello Dustin.
Weak events, or should I say the lack of them causing me headache as well.
That's why I was extremely pleased to stumble upon your excellent blog. However, I got different measurements, which make using LCG a very good alternative only slightly slower than using unbound delegates:
[normal]:
Subscribing one event handler takes about 0.55988 microseconds
Firing one event handler takes about 0.39475 microseconds
[weak by reflection]:
Subscribing one event handler takes about 19.2845 microseconds
Firing one event handler takes about 19.66328 microseconds
Subscribing is 34.4440 times slower
Firing is 49.8120 times slower
[weak by LCG]:
Subscribing one event handler takes about 91.05281 microseconds
Firing one event handler takes about 0.57962 microseconds
Subscribing is 162.6292 times slower
Firing is 1.4683 times slower
[weak by unbound delegate]:
Subscribing one event handler takes about 38.31363 microseconds
Firing one event handler takes about 0.56384 microseconds
Subscribing is 68.4319 times slower
Firing is 1.4283 times slower

I subscribe and fire 10000 times and use the Stopwatch class to measure the times.

Here is how I measure the times:

public double Subscribe(int count)
{
EventProvider provider = new EventProvider();
Stopwatch sw = new Stopwatch();
for (int i = 0; i < count; ++i)
{
sw.Start();
provider.MyEvent += new WeakEventHandler<EventArgs>(MyEventHandler);
sw.Stop();
provider.Reset(); // clears the event delegate
}
return (1000 * sw.Elapsed.TotalMilliseconds) / count;
}

public double Fire(int count)
{
EventProvider provider = new EventProvider();
provider.MyEvent += new WeakEventHandler<EventArgs>(MyEventHandler);

Stopwatch sw = new Stopwatch();
for (int i = 0; i < count; ++i)
{
provider.Fire(sw);
}
return (1000 * sw.Elapsed.TotalMilliseconds) / count;
}

Am I doing something wrong or is LCG indeed a very good option?
Thanks.

Most Active Users

What's this?