My apologies, I meant 250 times per minute, not per second, for the high read-rate PPS objects. I'm already caching the 
PPS data. I believe the ?delta option is of marginal benefit for these ~4Hz PPS objects since they only have 2 
attributes. The other PPS objects are updated very infrequently - typically once a day. 

Thanks for your help.

Chris Kilborn 
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201           v1: 224.216.2141
v2: 913.385.5700x307  f: 913.385.5701

Engage Success


-----Original Message-----
From: Douglas Bailey [mailto:community-noreply@qnx.com] 
Sent: Thursday, September 01, 2011 5:47 PM
To: general-community
Subject: RE: PPS object attribute order

Keep in mind that PPS is not intended as a high performance data channel.  Unless your attribute values are changing 
frequently, what you are suggesting is a really bad design.  All of those PPS reads will most likely be very inefficient
.  You should take Mario's suggestion and open the objects with ?delta and cache the values.  Use a second thread to do 
this reading if necessary.  Then you can order them in your own data structures however you like, and your 250hz read 
loop need only read the values from your own data structures -- much more efficient.


-----Original Message-----
From: John Kilbornn [mailto:community-noreply@qnx.com]
Sent: Thu 9/1/2011 14:24
To: general-community
Subject: RE: PPS object attribute order
 
That would work, but I was hoping for a simpler, generic way of handling it (i.e., it would have been nice if the order 
of attributes in the read buffer mirrored the order of attributes in the original write buffer -- seems logical!). Most 
of the PPS objects in our system have only a few attributes, so hash tables would be overkill for all but a few PPS 
objects. I'll probably just do string compares.

Thanks for the suggestion!

Chris Kilborn 
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201           v1: 224.216.2141
v2: 913.385.5700x307  f: 913.385.5701

Engage Success


-----Original Message-----
From: Mario Charest [mailto:community-noreply@qnx.com] 
Sent: Thursday, September 01, 2011 1:17 PM
To: general-community
Subject: RE: PPS object attribute order


Couldn't you cache them, register for notification if the entries changed, and update the cache as needed.  Then use 
whatever method you like to arrange the cache in the most efficient way, using the string as a hash key for example.

-----Message d'origine-----
De�: John Kilbornn [mailto:community-noreply@qnx.com] 
Envoy��: 1 septembre 2011 15:06
��: general-community
Objet�: RE: PPS object attribute order

Maximum would be reading 8 different PPS objects 250 times a second; each of these would have only 2 attributes, so only
 one 2 string compares. We have PPS Objects with many more attributes (> 10), but reads will be much more infrequent on 
these. 

I can probably get by with string comparisons, but it feels very inefficient for an embedded, real-time system. I assume
 there's no way to specify the order that attributes appear in the read buffer using the file descriptor argument of the
 read() routine?

Chris Kilborn
RBC MEDICAL INNOVATIONS
http://www.rbccorp.com
mailto: ckilborn@rbccorp.com
c: 312.287.5201           v1: 224.216.2141
v2: 913.385.5700x307  f: 913.385.5701

Engage Success


-----Original Message-----
From: Elena Laskavaia [mailto:community-noreply@qnx.com]
Sent: Thursday, September 01, 2011 12:58 PM
To: general-community
Subject: Re: PPS object attribute order

How many times per second it will read this object? I doubt string comparison would a bottleneck of you application

On 09/01/2011 01:53 PM, John Kilbornn wrote:
> Thanks. I'm not counting on it; I'm trying to work around it. 
> 
> I rather not do string compares on just-read attribute names to 
> associate them with...