EnumWindows - Speed

[Tim Chase]

I have found that EnumWindows works very quickly. In DotNet (I use
C#), I can enumerate the windows, narrow them down to just the windows
which are the main windows (i.e., windows which you can alt-tab to),
identify the associated executables, group by executable, sort the
executables alphabetically, then sort the main windows alphabetically
once they have been grouped by executables, and have this done without
the user noticing any delay when the entire process is initiated each
time by clicking on a menu. The process fills the menu with menuitems
(the executables) then sub-menuitems (the main windows). However,
there is a fairly appreciable delay when enumerating all processes and
their modules (including the dll modules), then representing the
information in treeview.

The differences? When performing working with the windows, I am using
p/invoke (i.e., static intern) to call Win32 api functions rather than
the DotNet api, representing a great deal less data (although the
amount of data I am making use of may be at least as great), and using
a menu rather than a treeview. I am beginning to think that greater
use of the ability to intelligently set the capacity could speed
things up (with respect to the treeview), but I am also beginning to
the that greater emphasis needs to be placed by the developers of
DotNet on the optimization of their api, at least within certain parts
of System.Diagnostics. Has anyone had similiar (or different)
experiences?

 

[Nicholas Paldino [.NET/C# MVP]]

Tim,

Such is the case when you are working with a framework of such size and
magnitude. To be honest, it is hard to appease everyone, and the design and
implementation of features in the framework are usually chosen because they
will be the most productive for the greatest audience (while still being the
correct design, of course).

That being said, speaking specifically about the classes in the
System.Diagnostic namespace, which classes are you speaking about? Are you
speaking about the Process class? Right now, there is some overhead in
enumerating processes on a machine, as it does a lot of checking to see if
the process is on another machine, if the process is running (the same class
is used to get currently running processes and create new processes), etc,
etc.

If it is another class, which is it?

Hope this helps.

 

[Tim Chase]

Nicholas,

You are quite right. The Win32 calls I am making for windows is
specific to the machine. The Process class in the System.Diagnostics
namespace is specifically designed for working over a network -- which
is the context in which it will be most useful. If all I am looking
for is information specific to my own machine, there are Win32 calls
for that. At the same time, I am not entirely sure that I have
optimized the code that I am using.

Take care,
Tim

Tim,

Such is the case when you are working with a framework of such size and
magnitude. To be honest, it is hard to appease everyone, and the design and
implementation of features in the framework are usually chosen because they
will be the most productive for the greatest audience (while still being the
correct design, of course).

That being said, speaking specifically about the classes in the
System.Diagnostic namespace, which classes are you speaking about? Are you
speaking about the Process class? Right now, there is some overhead in
enumerating processes on a machine, as it does a lot of checking to see if
the process is on another machine, if the process is running (the same class
is used to get currently running processes and create new processes), etc,
etc.

If it is another class, which is it?

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I have found that EnumWindows works very quickly. In DotNet (I use
C#), I can enumerate the windows, narrow them down to just the windows
which are the main windows (i.e., windows which you can alt-tab to),
identify the associated executables, group by executable, sort the
executables alphabetically, then sort the main windows alphabetically
once they have been grouped by executables, and have this done without
the user noticing any delay when the entire process is initiated each
time by clicking on a menu. The process fills the menu with menuitems
(the executables) then sub-menuitems (the main windows). However,
there is a fairly appreciable delay when enumerating all processes and
their modules (including the dll modules), then representing the
information in treeview.

The differences? When performing working with the windows, I am using
p/invoke (i.e., static intern) to call Win32 api functions rather than
the DotNet api, representing a great deal less data (although the
amount of data I am making use of may be at least as great), and using
a menu rather than a treeview. I am beginning to think that greater
use of the ability to intelligently set the capacity could speed
things up (with respect to the treeview), but I am also beginning to
the that greater emphasis needs to be placed by the developers of
DotNet on the optimization of their api, at least within certain parts
of System.Diagnostics. Has anyone had similiar (or different)
experiences?

 

[Nicholas Paldino [.NET/C# MVP]]

Tim,

If you are finding that you get the speed you need from calls through
the P/Invoke layer, then by all means, use them. However, just remember
that you are losing out on the fact that the object model is already there.
Ultimately, this is something you have to decide (dev time vs performance).

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Nicholas,

You are quite right. The Win32 calls I am making for windows is
specific to the machine. The Process class in the System.Diagnostics
namespace is specifically designed for working over a network -- which
is the context in which it will be most useful. If all I am looking
for is information specific to my own machine, there are Win32 calls
for that. At the same time, I am not entirely sure that I have
optimized the code that I am using.

Take care,
Tim

"Nicholas Paldino [.NET/C# MVP]" <[email protected]> wrote

Tim,

Such is the case when you are working with a framework of such size and
magnitude. To be honest, it is hard to appease everyone, and the design and
implementation of features in the framework are usually chosen because they
will be the most productive for the greatest audience (while still being the
correct design, of course).

That being said, speaking specifically about the classes in the
System.Diagnostic namespace, which classes are you speaking about? Are you
speaking about the Process class? Right now, there is some overhead in
enumerating processes on a machine, as it does a lot of checking to see if
the process is on another machine, if the process is running (the same class
is used to get currently running processes and create new processes), etc,
etc.

If it is another class, which is it?

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I have found that EnumWindows works very quickly. In DotNet (I use
C#), I can enumerate the windows, narrow them down to just the windows
which are the main windows (i.e., windows which you can alt-tab to),
identify the associated executables, group by executable, sort the
executables alphabetically, then sort the main windows alphabetically
once they have been grouped by executables, and have this done without
the user noticing any delay when the entire process is initiated each
time by clicking on a menu. The process fills the menu with menuitems
(the executables) then sub-menuitems (the main windows). However,
there is a fairly appreciable delay when enumerating all processes and
their modules (including the dll modules), then representing the
information in treeview.

The differences? When performing working with the windows, I am using
p/invoke (i.e., static intern) to call Win32 api functions rather than
the DotNet api, representing a great deal less data (although the
amount of data I am making use of may be at least as great), and using
a menu rather than a treeview. I am beginning to think that greater
use of the ability to intelligently set the capacity could speed
things up (with respect to the treeview), but I am also beginning to
the that greater emphasis needs to be placed by the developers of
DotNet on the optimization of their api, at least within certain parts
of System.Diagnostics. Has anyone had similiar (or different)
experiences?