Results 1 to 7 of 7
  1. #1
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Performance using Event Sinks (2002)

    Does anyone have any experience they could share on relative performance of event sinks for subform events as opposed to direct calls into public methods of a subform? How about raising custom events compared to built in events? My boss isn't familiar with using WithEvents and sinking events so he is concerned that there might be a perceivable difference in performance using that method over a direct call. I've used them for years and have never noticed any difference, but I've never done an actual side-by-side comparison. Has anyone else? <img src=/S/help.gif border=0 alt=help width=23 height=15>
    Charlotte

  2. #2
    WS Lounge VIP rory's Avatar
    Join Date
    Dec 2000
    Location
    Burwash, East Sussex, United Kingdom
    Posts
    6,280
    Thanks
    3
    Thanked 191 Times in 177 Posts

    Re: Performance using Event Sinks (2002)

    Charlotte,
    This quote from an MSDN article may not be a complete answer in that the callback reference is not entirely relevant (my assumption would be that calling a method must be inherently more direct than raising the event by the same reasoning and I have removed some of the less relevant info) but I think it goes towards the point:
    <hr>Ken Bergmann
    MSDN Content Development Group

    April 1997

    It can be hard to understand when to use an event (or connection point) interface and when to use a specific callback interface. The two, while similar, can vary greatly in a number of ways. The following will outline some fundamental issues that should be considered when attempting to decide how to proceed with your components.

    Do I Know You?
    The key conceptual difference between an event interface and a callback interface is that an event is designed to be more like an anonymous broadcast, while a callback functions more like a handshake. While other important issues will need to be addressed, most decisions about which technique to use will pivot around this anonymity.

    Getting Intimate
    Any object that has a reference to an event source can handle the events the source raises by simply placing that reference into a WithEvents variable. In C++, handling connection points is a little more involved, but the premise is the same. In either case, the event source has no idea what objects may be handling its events. There may be a hundred objects paying close attention or there may be none. The key point is that the event source blindly notifies each connected client through its event (connection point) interface, without any knowledge of whether the client is handling the event or what the interface to the client actually looks like.

    In contrast, a server designed to perform callbacks must have an explicit reference to every object that needs notification, it must connect and manage those references, and, finally, it must perform the notification. Basically, the server must know exactly how many clients there are and how to connect and interact with each of them.
    ...
    Who's In Charge?
    When an event server raises an event, all of its clients get the opportunity to handle that event before the event server can regain control. So, if many clients are listening for events, the notification process could take an unforeseeable length of time. On the other hand, a callback server, because it is responsible for implementing the notification process, regains control after each call it makes to a client. Because of the level of control available here, callbacks can employ much more intelligent techniques for client notification than events.

    Now, let's consider what happens to the arguments of an event. Because the event server doesn't regain control until after all clients have handled a specific event, the changes to a ByRef argument by a specific client are lost. Only the changes to an argument made by the last client are seen by the event server. This becomes really inconvenient when considered with the fact that the order in which clients are notified cannot be assured. Of course, with a callback server, the server is responsible for this process, so each client's feedback can be analyzed independently. In fact, a callback server might wish to pass fresh values when notifying each client.

    Handling Errors
    The final compelling difference between the two approaches is the way in which errors are handled. If an error occurs in a client's event handler, the event source is not notified. The client handling the event might even be brought down very horribly, and the event source would never know. Of course, the client's fatal error is just as likely to bring the event server down, too (if it's an in-process component). In this case, the event server will have no clue why it was brought down, or even that an error occurred.

    However, a callback server will receive notification of errors that occur in the callback methods of its clients, and, as such, must be prepared to handle them. Of course, this expectation is true of any COM interface.

    Performance Issues
    When performance is at stake, it will usually be worthwhile to do the extra work required to create custom callback interfaces. By employing early binding in the callback interface connection code, significant improvements can be made in high-volume or in-process components. By design, event interfaces are not vtable bound and are, therefore, slower in most scenarios than comparable early-bound callback interfaces.

    Of course, in any performance issue, the only way to gauge your own needs is to experiment, benchmark, and test. Try out the various permutations yourself and do the math. If you really care about getting the absolute last spurt of speed, then doing the tests is the only way to prove what works, no matter what promises are made.
    <hr>
    The last line is particularly telling!! <img src=/S/grin.gif border=0 alt=grin width=15 height=15>
    Regards,
    Rory

    Microsoft MVP - Excel

  3. #3
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Performance using Event Sinks (2002)

    <hr>doing the tests is the only way to prove what works<hr>
    Thanks a *lot*, Rory! <img src=/S/bummer.gif border=0 alt=bummer width=15 height=15> Fat lot of help you are! <img src=/S/wink.gif border=0 alt=wink width=15 height=15>

    I'm not sure the article applies at all, though, because this appears to be aimed at independent objects like COM objects rather than the rather more closely controlled series of events within a form and its subforms. And I have to admit, I got totally lost in the abstractions in there. <img src=/S/dizzy.gif border=0 alt=dizzy width=15 height=15> After a paragraph or so, I couldn't figure out whether we were talking about the client or server and, in fact, which one was raising the event! Oh, well. I never claimed to do COM or understand C++. <img src=/S/shrug.gif border=0 alt=shrug width=39 height=15>
    Charlotte

  4. #4
    WS Lounge VIP rory's Avatar
    Join Date
    Dec 2000
    Location
    Burwash, East Sussex, United Kingdom
    Posts
    6,280
    Thanks
    3
    Thanked 191 Times in 177 Posts

    Re: Performance using Event Sinks (2002)

    Hey, I didn't say it was necessarily all relevant! <img src=/S/wink.gif border=0 alt=wink width=15 height=15> - but I think the principle applies.
    My suspicion would be that, although the WithEvents creates an anonymous broadcast (as it would in any COM object) rather than a direct call, because these events are more specialised (so in that sense less anonymous) in Access forms/subforms, the possible delays in response would be pretty much negligible - the broadcast is, if nothing else, application-specific rather than system-wide. I'd equate it to the difference between yelling "Someone get that phone" as opposed to "Rory, get that phone" when there are 2 people present.
    I still stand by the last line, though!
    Regards,
    Rory

    Microsoft MVP - Excel

  5. #5
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Performance using Event Sinks (2002)

    Uh, did I mention that the "direct" calls would be from other subforms on the same parent form, so a call would have to go through the parent form's reference to get to the other subform's public method?
    Charlotte

  6. #6
    WS Lounge VIP rory's Avatar
    Join Date
    Dec 2000
    Location
    Burwash, East Sussex, United Kingdom
    Posts
    6,280
    Thanks
    3
    Thanked 191 Times in 177 Posts

    Re: Performance using Event Sinks (2002)

    No worries - they're all in-process event servers. <img src=/S/innocent.gif border=0 alt=innocent width=20 height=20> Probably.
    Regards,
    Rory

    Microsoft MVP - Excel

  7. #7
    Super Moderator
    Join Date
    Aug 2001
    Location
    Evergreen, CO, USA
    Posts
    6,624
    Thanks
    3
    Thanked 60 Times in 60 Posts

    Re: Performance using Event Sinks (2002)

    I found this web article interesting. My own view of the performance world is that Pareto's Law should be applied first - and this one smacks of being in the noise level, and thus not a concern. It seems logical that there might be a bit more overhead raising your own event (that assumes the Access developers wrote nice tight code to handle the intrinsic events), but unless the event is being fired thousands of times each minute, the overhead would be negligible.
    Wendell

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •