Will many ToolTip providers cause a performance issue?

[Rachel Suddeth]

I have an application where some forms have many (say 100) UserControls on
them (each of which contain a label, an image, and a data entry control),
and each UserControl has a ToolTip provider (although really we don't assign
ToolTips to most of the controls), and then the UserControl exposes a
ToolTipText property which sets the same ToolTip for all 3 contained
controls. It would be possible to have one ToolTip provider on the form
instead, it would be ugly (especially since I think the form level ToolTip
provider would put provider-properties on the designer property thingy that
we'd want to NEVER use.)

Anyway, our more complex forms are loading kinda slow, and my supervisor
wonders if it would help performance if each control did not have its own
ToolTip provider. I think this is not the big issue, but I don't know enough
about how the ToolTip works internally to feel sure. I suppose the only real
way to know is try removing them, and see if it helps, but that will be a
real pain, and if anyone has enough knowledge to say we really should be
looking somewhere else, that'd be appreciated. Or to say yes, removing the
100 ToolTip providers is really worth trying (either way.)

-Rachel

[Bob Powell [MVP]]

Tool tips are provided through an extender provider that associates the
tooltip message with the control via a hashtable. You should not have many
tooltip object, just one...

The tooltip system works by adding a handler to the controls mouse-hover
event and then showing the message associated with the control. There should
be no particular performance loss.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"Rachel Suddeth" <ra****@bldhoun d.com> wrote in message
news:OS******** ******@TK2MSFTN GP12.phx.gbl...

I have an application where some forms have many (say 100) UserControls on
them (each of which contain a label, an image, and a data entry control),
and each UserControl has a ToolTip provider (although really we don't
assign
ToolTips to most of the controls), and then the UserControl exposes a
ToolTipText property which sets the same ToolTip for all 3 contained
controls. It would be possible to have one ToolTip provider on the form
instead, it would be ugly (especially since I think the form level ToolTip
provider would put provider-properties on the designer property thingy
that
we'd want to NEVER use.)

Anyway, our more complex forms are loading kinda slow, and my supervisor
wonders if it would help performance if each control did not have its own
ToolTip provider. I think this is not the big issue, but I don't know
enough
about how the ToolTip works internally to feel sure. I suppose the only
real
way to know is try removing them, and see if it helps, but that will be a
real pain, and if anyone has enough knowledge to say we really should be
looking somewhere else, that'd be appreciated. Or to say yes, removing the
100 ToolTip providers is really worth trying (either way.)

-Rachel

[Rachel Suddeth]

Thanks, Bob...

The tooltip system works by adding a handler to the controls mouse-hover
event and then showing the message associated with the control. There should be no particular performance loss.
I take it you are saying there is not much overhead in having many
hashtables with only a few (or no) entries each, then having one hashtable
with many entries? Obviously, the latter is more efficient, but I think not
a big deal?
Tool tips are provided through an extender provider that associates the
tooltip message with the control via a hashtable. You should not have many
tooltip object, just one...

The problem with sticking one ToolTip provider onto the form when you are
using UserControls is that if you do SetToolTip(cont rol, tiptext), that will
associate the text only with UserControl's mouse events, not with the
contained controls' events. If the contained controls cover the entire
surface of the UserControl (as most of them do for us), then the TipText
will never show up. Instead, we have one for each UserControl, and the set
of the TipText does something like
set
{
foreach ( Control c in this.Controls )
{
this.TipProvide r.SetToolTip( c, value );
}
}
(Really, it's a bit more complicated that this because sometimes the
contained control can itself be a container.) The contained controls are
private members of the UserControl, and we'd like to keep it that way, so
using a single ToolTip for the whole for would be messy and involve the
UserControl having access to the form's ToolTip provider.

-Rachel

[Pete Davis]

Rachel,

The first thing I'd do, if I were you, instead of spending a lot of time
trying to optimize things you're not sure will make a difference, is profile
your app and find out specifically where the bottleneck is. That way you
won't waste a great deal of time on things that may not make any noticeable
difference.

I highly recommend nprof. It works really well and it's free:

http://nprof.sourceforge.net/Site/SiteHomeNews.html

My job is primarily developping custom controls, and for some of them,
performance is a high priority issue. nprof has been a life saver.

Pete

"Rachel Suddeth" <ra****@bldhoun d.com> wrote in message
news:ef******** ******@TK2MSFTN GP12.phx.gbl...

Thanks, Bob...

The tooltip system works by adding a handler to the controls mouse-hover
event and then showing the message associated with the control. There

should

be no particular performance loss.

I take it you are saying there is not much overhead in having many
hashtables with only a few (or no) entries each, then having one hashtable
with many entries? Obviously, the latter is more efficient, but I think
not
a big deal?

Tool tips are provided through an extender provider that associates the
tooltip message with the control via a hashtable. You should not have
many
tooltip object, just one...

The problem with sticking one ToolTip provider onto the form when you are
using UserControls is that if you do SetToolTip(cont rol, tiptext), that
will
associate the text only with UserControl's mouse events, not with the
contained controls' events. If the contained controls cover the entire
surface of the UserControl (as most of them do for us), then the TipText
will never show up. Instead, we have one for each UserControl, and the set
of the TipText does something like
set
{
foreach ( Control c in this.Controls )
{
this.TipProvide r.SetToolTip( c, value );
}
}
(Really, it's a bit more complicated that this because sometimes the
contained control can itself be a container.) The contained controls are
private members of the UserControl, and we'd like to keep it that way, so
using a single ToolTip for the whole for would be messy and involve the
UserControl having access to the form's ToolTip provider.

-Rachel

[Bob Powell [MVP]]

I have not found that hashtable performance was much of a problem under many
hundreds of entries. If your form has many hundreds of items then it's
probably way too busy and you should be doing something else.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"Rachel Suddeth" <ra****@bldhoun d.com> wrote in message
news:ef******** ******@TK2MSFTN GP12.phx.gbl...

Thanks, Bob...

The tooltip system works by adding a handler to the controls mouse-hover
event and then showing the message associated with the control. There

should

be no particular performance loss.

I take it you are saying there is not much overhead in having many
hashtables with only a few (or no) entries each, then having one hashtable
with many entries? Obviously, the latter is more efficient, but I think
not
a big deal?

Tool tips are provided through an extender provider that associates the
tooltip message with the control via a hashtable. You should not have
many
tooltip object, just one...

The problem with sticking one ToolTip provider onto the form when you are
using UserControls is that if you do SetToolTip(cont rol, tiptext), that
will
associate the text only with UserControl's mouse events, not with the
contained controls' events. If the contained controls cover the entire
surface of the UserControl (as most of them do for us), then the TipText
will never show up. Instead, we have one for each UserControl, and the set
of the TipText does something like
set
{
foreach ( Control c in this.Controls )
{
this.TipProvide r.SetToolTip( c, value );
}
}
(Really, it's a bit more complicated that this because sometimes the
contained control can itself be a container.) The contained controls are
private members of the UserControl, and we'd like to keep it that way, so
using a single ToolTip for the whole for would be messy and involve the
UserControl having access to the form's ToolTip provider.

-Rachel

[Rachel Suddeth]

"Bob Powell [MVP]" <bob@_spamkille r_bobpowell.net > wrote in message
news:OH******** *****@TK2MSFTNG P09.phx.gbl...

I have not found that hashtable performance was much of a problem under many hundreds of entries. If your form has many hundreds of items then it's
probably way too busy and you should be doing something else.

Oh, dear, I have not been clear. I am saying that IF there is a performance
difference, it will be more efficient to use only one hashtable. I am sure
the hastable could easily handle all the entries ... it would be a poor
hashtable implementation if it couldn't (which seems terribly unlikely given
that hashtables aren't hard to implement and Microsoft has very smart
programmers.) It's rather a waste of space to use a hashtable for only 2 or
3 entries... but I doubt that's our biggest problem.

Anyway, thanks for the info... I thought it would use a hashtable (that's
what I'd use if writing a provider), but it's nice to have that confirmed.

-Rachel

[Rachel Suddeth]

Thanks, Pete. I will get this right away. I do think it's time for us to use
something this.
-Rachel

"Pete Davis" <pdavis68@[nospam]hotmail.com> wrote in message
news:JM******** *************** *******@giganew s.com...

Rachel,

The first thing I'd do, if I were you, instead of spending a lot of time
trying to optimize things you're not sure will make a difference, is profile your app and find out specifically where the bottleneck is. That way you
won't waste a great deal of time on things that may not make any noticeable difference.

I highly recommend nprof. It works really well and it's free:

http://nprof.sourceforge.net/Site/SiteHomeNews.html

My job is primarily developping custom controls, and for some of them,
performance is a high priority issue. nprof has been a life saver.

Pete

[Rachel Suddeth]

Oh, why didn't I catch on to this?...

"Bob Powell [MVP]" <bob@_spamkille r_bobpowell.net > wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

...
The tooltip system works by adding a handler to the controls mouse-hover
event ...

In that case, I should be able to add a MouseHover handler to all the
controls on each user control like so...

private void BaseCtrl_Contro lAdded(object sender, ControlEventArg s e)
{
Control c = sender as Control;
c.MouseHover += new EventHandler(c_ MouseHover);
}

private void c_MouseHover(ob ject sender, EventArgs e)
{
this.OnMouseHov er(e);
}

Then I should be able to use the ToolTip as intended, because hovering over
any contained control should trigger the UserControl's MouseHover, right?

-Rachel

[Registered User]

On Mon, 7 Nov 2005 09:08:57 -0600, "Rachel Suddeth"
<ra****@bldhoun d.com> wrote:

Thanks, Pete. I will get this right away. I do think it's time for us to use
something this.
-Rachel
In your original post you mention that some forms have over 100 user
controls and each user control contains three controls including an
image. Just knowing this it becomes obvious a whole lot, perhaps too
much, is going on as the form loads. Loading 100+ images sounds like a
lot of repetitive I/O. Populating 100+ data controls will slow things
down as well.

As a programmer I have to question to the design and as a designer I
have to question the usability of a window with 100+ controls. Such
complexity cannot be user-friendly.

regards
A.G.
"Pete Davis" <pdavis68@[nospam]hotmail.com> wrote in message
news:JM******* *************** ********@gigane ws.com...

Rachel,

The first thing I'd do, if I were you, instead of spending a lot of time
trying to optimize things you're not sure will make a difference, is

profile

your app and find out specifically where the bottleneck is. That way you
won't waste a great deal of time on things that may not make any

noticeable

difference.

I highly recommend nprof. It works really well and it's free:

http://nprof.sourceforge.net/Site/SiteHomeNews.html

My job is primarily developping custom controls, and for some of them,
performance is a high priority issue. nprof has been a life saver.

Pete