• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 779
  • Last Modified:

Performance implications of adding events to classes in VBA

As part of several Excel/Access/VBA automation projects I'm currently involved in, I'm creating some generic reusable classes with different functionality.

In some of these it seems convenient to add some events for different state changes. However some of these objects need to handle very large amounts of data very quickly, so I'm trying to optimize performance in every part of the code I'm doing, and this raised the following questions regarding events:

1. What is the performance implication of adding event raisers to procedures? In some procedures RaiseEvent will potentially be called very often, so this is important.

2. If the class is declared without the WithEvents keyword is the RaiseEvent lines then completely ignored and will not have any perfect on performance at all?
2 Solutions
If the developer/user doesn't code anything in the event, then it is the equivalent of not being called.  The compiler is smart enough to skip.  If there is code in that event, then it is usually viewed as a synchronous event.  I think there might be ways of coding that aren't exactly synchronous, but it gets tricky, and any such events might thwart your rapid response design/performance.

I don't know about the second part of your question.
Calling Raisevent in itself does not really have a siginificant performance implication. The perfomance implicaitons of the event come in how the event handler is programmed i.e. what it does and that is where perfomance is a concern. As aikimark already points out, the Visual Basic .NET compiler assists you by automatically adding a private delegate field and a public registration method whenever you define an event (reference) and the RaiseEvent statement automatically checks to verify if an event handler exists before raising the event. If the event is Nothing, then there’s no event handler and RaiseEvent terminates. If the event is not Nothing, then RaiseEvent triggers the event (reference). For asyncronous events and delegates, I'd refer you to google.

Part 2: WithEvents keyword is the RaiseEvent lines then completely ignored
Without the WithEvents keyword, the object will not raise events. It does not mean that RaiseEvents lines are completely ignored, technically, there is probably some logic inserted by the compiler which first checks whether events are enabled and then whether an event handler is actually defined BEFORE the runtime raises the event - the performance cost of doing this is negligible. However, the end results are that in Visual Basic, events are only raised if the object is declared WithEvents (and therefore the event handler will NOT be called, even if it is defined).
andreas_rafnAuthor Commented:
Very enlightening, thanks for the answers. I'm beginning to realize that putting some time into understanding the way compilation of the VBA code works might make things a lot easier in the future.

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now