Re: performance problem with IORegistryEntryCreateCFProperties
Re: performance problem with IORegistryEntryCreateCFProperties
- Subject: Re: performance problem with IORegistryEntryCreateCFProperties
- From: Raleigh Ledet <email@hidden>
- Date: Tue, 9 Dec 2008 10:28:15 -0800
I totally agree with Herb here. If matching on a specific serial
number is not feasible, at the very least, match on the
IOHIDDevicesKey. As opposed to polling, you will be informed with the
HID topology changes.
One very important note though. I would avoid calling
IORegistryEntryCreateCFProperties() unless you are the creator of the
device. IORegistryEntryCreateCFProperties() can be expensive,
especially if all you want is the serial number. Use
IORegistryEntryCreateCFProperty() to just get the serial number.
Why is IORegistryEntryCreateCFProperties() so bad?... well it causes
the entire HID descriptor to be parsed, and there are some devices
(certain keyboards) that have cause the parsing to expand into
hundreds of elements. If seen this effectively stall the machine.
Thus, making multiple calls to IORegistryEntryCreateCFProperty() to
get a handful of properties is much better than creating the full
dictionary.
-raleigh
On 09 Dec,2008, at 9:01 AM, Herb Petschauer wrote:
Out of curiosity, why spawn a second thread to poll when you can use
IOServiceAddMatchingNotification() [and friends, search in
/Developer/Examples] to get you notifications of devices appearing and
disappearing? That is going to faster than walking the entire
IORegistry every time to find the matches which is effectively what
IOServiceGetMatchingServices() is going to be doing [do an "ioreg -l"
in Terminal window to get the full list]
Cheers,
-H.
2008/12/8 Brad Justice <email@hidden>:
My application spawns a POSIX background thread that polls for
certain
hardware changes. I have found that according to Activity Monitor
and BigTop
it is consuming about 5% of the CPU, which seems inexplicable to me.
The thread loop calls sleep(2) and then begins its checks. Setting
Activity
Monitor granularity to 0.5 seconds, I find that every 4 periods the
thread
consumes 20% of the CPU, and 0 % for the other three. By commenting
out
sections of code, I have isolated the CPU usage to one loop that
executes 7
times. I have confirmed the number of iterations by single stepping
in the
debugger.In particular, the execution of seven paired calls to
IORegistryEntryCreateCFProperties and CFRelease result in 5% CPU
usage on my
MacBook Pro according to my tools.
Am I misinterpreting my tools, is this an Activity Monitor bug, or
are
IORegistryEntryCreateCFProperties and CFRelease heavily CPU
intensive for
some reason? It seems to me seven calls every two seconds should not
register activity at this level.
Thanks for any advice that you can provide. Source for the
offending loop
below.
classToMatch = IOServiceMatching (kIOHIDDeviceKey);
if (classToMatch)
{ numberRef = NULL; mach_port_t
mport =
[myList getMasterport];
result =
IOServiceGetMatchingServices(mport,classToMatch,&iterator);
if (KERN_SUCCESS == result) {
if(iterator)
{
while( ( serviceObject = IOIteratorNext
( iterator ) ) )
{
CFMutableDictionaryRef hidProperties = 0;
result = IORegistryEntryCreateCFProperties
(serviceObject, &hidProperties, kCFAllocatorDefault, kNilOptions);
if (result == KERN_SUCCESS)
{
serialNumberValue = (NSString *)
CFDictionaryGetValue(hidProperties,CFSTR("SerialNumber"));
if (serialNumberValue != NULL)
{
range = [serialNumberValue
rangeOfString:matchingString];
if (range.length != 0)
{
count++;
}
}
}
CFRelease(hidProperties);
}
IOObjectRelease(iterator);
} } }
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden