using System.Manageme nt a faux pas?

[not_a_commie]

Is using System.Manageme nt in general a faux pas? It seems, after some
web searching, that there is a fair amount of resistance to it because
of speed and portability.

I need to know how many CPU sockets there are. I'm using
System.Manageme nt to do this. It takes about two seconds to do this.
(Which, yes, is full-on crap for speed.) But what is the better way to
determine the number of CPU sockets in Windows version >= 5 with
a .NET >= 2.0 application?

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

not_a_commie,

With the System.Manageme nt namespace, you are trading off performance
for ease-of-use, and maintainability (through a unified object model and
query syntax). I am sure that there is much faster code to find this out,
but it is most likely done with interop, which if not done correctly, can
impact ease-of-use and maintainability .

So in the end, it is a trade off, and like all trade offs, you have to
make the decision which one is better for your application's needs.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"not_a_comm ie" <no********@gma il.comwrote in message
news:11******** *************@d 30g2000prg.goog legroups.com...

Is using System.Manageme nt in general a faux pas? It seems, after some
web searching, that there is a fair amount of resistance to it because
of speed and portability.

I need to know how many CPU sockets there are. I'm using
System.Manageme nt to do this. It takes about two seconds to do this.
(Which, yes, is full-on crap for speed.) But what is the better way to
determine the number of CPU sockets in Windows version >= 5 with
a .NET >= 2.0 application?

[Willy Denoyette [MVP]]

"not_a_comm ie" <no********@gma il.comwrote in message
news:11******** *************@d 30g2000prg.goog legroups.com...

Is using System.Manageme nt in general a faux pas? It seems, after some
web searching, that there is a fair amount of resistance to it because
of speed and portability.

I need to know how many CPU sockets there are. I'm using
System.Manageme nt to do this. It takes about two seconds to do this.
(Which, yes, is full-on crap for speed.) But what is the better way to
determine the number of CPU sockets in Windows version >= 5 with
a .NET >= 2.0 application?

Environment.Pro cessorCount, returns the number of processors, but this is
not what you are looking for.
Getting the CPU unit count from WMI should however not take more than 50
msecs.
What OS and what WMI class are you using for this.

Willy.

[Willy Denoyette [MVP]]

"Willy Denoyette [MVP]" <wi************ *@telenet.bewro te in message
news:uh******** ******@TK2MSFTN GP06.phx.gbl...

"not_a_comm ie" <no********@gma il.comwrote in message
news:11******** *************@d 30g2000prg.goog legroups.com...

>Is using System.Manageme nt in general a faux pas? It seems, after some
web searching, that there is a fair amount of resistance to it because
of speed and portability.

I need to know how many CPU sockets there are. I'm using
System.Managem ent to do this. It takes about two seconds to do this.
(Which, yes, is full-on crap for speed.) But what is the better way to
determine the number of CPU sockets in Windows version >= 5 with
a .NET >= 2.0 application?

Environment.Pro cessorCount, returns the number of processors, but this is
not what you are looking for.
Getting the CPU unit count from WMI should however not take more than 50
msecs.
What OS and what WMI class are you using for this.

Willy.

Following:
int processors;
SelectQuery query = new SelectQuery("se lect Deviceid from
Win32_Processor ");
using(Managemen tObjectSearcher searcher = new
ManagementObjec tSearcher(query ))
{
ManagementObjec tCollection processor= searcher.Get();
processors = processor.Count ;
}

takes 30...40msecs. when run on my box.
Note that the very first call can take some more time on some OS versions,
as the system has to start WMI (when not already).
started, anyway, this should be *much* less than 2 seconds, provided your
system is not running low on CPU or/and memory resources.

Willy.

[not_a_commie]

I'm using WinXP SP2 on a core 2 duo. I'm thinking that my timer is
getting thrown off because this is being loaded in a static
constructor with other assemblies being loaded at the same time.
Here's the code:

if (Environment.OS Version.Version .Major >= 6 ||
Environment.OSV ersion.Platform == PlatformID.Unix )
return; // the bug we're working around exists in WinXP and older

ManagementClass mc = new ManagementClass ("Win32_Process or");
ManagementObjec tCollection mos = mc.GetInstances (); // get all the
processors from the device manager
List<stringcpuS ockets = new List<string>();

foreach (ManagementObje ct mo in mos)
{
string socketDesc =
mo.SystemProper ties["SocketDesignat ion"].Value.ToString ();
if(!cpuSockets. Contains(socket Desc))
cpuSockets.Add( socketDesc);
}

if (cpuSockets.Cou nt 1)
{
// my special handling here
}

[not_a_commie]

So can I do something like this?

"select unique SocketDesignati on from Win32_Processor "

[not_a_commie]

So I thought that

"select SocketDesignati on from Win32_Processor group by
SocketDesignati on"

would work (I would just use the count rows returned from that query).
Alas, it does not. Is SocketDesignati on not the same as
["SocketDesignat ion"].Value? Or does the "group by" in WQL just behave
in a fishy manner? This query throws an exception:

"select count(*) from Win32_Processor group by SocketDesignati on"

[Willy Denoyette [MVP]]

"not_a_comm ie" <no********@gma il.comwrote in message
news:11******** *************@x 35g2000prf.goog legroups.com...

So can I do something like this?

"select unique SocketDesignati on from Win32_Processor "

No, but if you are only interested in a single CPU's properties, you can do
the following to get at a specific instance.

string objPath = "Win32_Processo r.DeviceId='CPU 0'";
string socketType;
using(Managemen tObject service = new ManagementObjec t( new
ManagementPath( objPath)))
{
socketType = service.Propert ies["SocketDesignat ion"].Value.ToString ();
}

Willy.

[Willy Denoyette [MVP]]

"not_a_comm ie" <no********@gma il.comwrote in message
news:11******** **************@ i38g2000prf.goo glegroups.com.. .

So I thought that

"select SocketDesignati on from Win32_Processor group by
SocketDesignati on"

would work (I would just use the count rows returned from that query).
Alas, it does not. Is SocketDesignati on not the same as
["SocketDesignat ion"].Value? Or does the "group by" in WQL just behave
in a fishy manner? This query throws an exception:

"select count(*) from Win32_Processor group by SocketDesignati on"

While WQL looks like SQL it is not a full fledged SQL.

Willy.

[not_a_commie]

No, but if you are only interested in a single CPU's properties, you can do

the following to get at a specific instance.
...
socketType = service.Propert ies["SocketDesignat ion"].Value.ToString ();

I'm interested in the count of unique SocketDesignati on values --
nothing else. It's creating instances of these objects that takes the
time, not the WQL. I was hoping to get all the information I needed
using WQL.