En Fri, 05 Jun 2009 12:33:04 -0300, Hendrik van Rooyen
<m...@microcorp.co.za> escribió:
"Gabriel Genellina" <ga....@yahoo.com.ar> wrote:
But if you already have a queue, you may put other objects there
(instead
of "canning" them). Testing the object type with isinstance(msg, str) is
pretty fast, and if you bind locally those names I'd say the overhead is
negligible.
Maybe you are right and I am pre optimising - but the heart of this
box really is that silly loop and the processor really is not fast at
all.
From your description of the problem, it seems you are acting upon
messages received from a serial port. You have to process the message
*before* the next one arrives -- but you gain nothing doing that much
faster. In other words, even with a blazingly fast processor, you can't do
things faster than the rate of incoming messages.
In any case, you have to test-and-branch in the code. Either with
isinstance(rec,str), either with rec_list[0]=="B", or something. I'm
unsure if this is the fastest approach - intuition doesn't play well with
timings in Python, better to actually measure times.
This is what I was trying to avoid, as it is important to get as much
performance out of the box as I can (given that I am using Python to
get the job done fast, because that is also important). So it is a kind
of
juggling with priorities - "make it fast" would imply do not use python,
but "get it done quickly" implies using python, and it looks to me that
if I am careful and think more like an assembler programmer, the
real time performance will be adequate. And I do not want to do
anything that could conceivably compromise that. Even if it means
jumping through a funny hoop like I am doing now, and inventing
a weird way to pass an object.
If it works and you feel it's adequate, that's fine. I cannot count how
many times I've used an integer property to attach a pointer to another
object (in other languages), but I felt "dirty" doing that. And never did
something like that in Python...
So to a large extent I think that I am doing the job as fast as it is
possible - the comma delimited input string is a fact, decided on
between myself and the customer a long time ago, and it comes over
a socket, so it has to be a string. The least I can do with it is
nothing
before I put it on the critical queue. Then when it comes out of the
queue, I have to break it up into its constituent parts, and I would
think
that split is the canonical way of doing that.
Ok, what if you split *before* putting in the queue? In the receiving side
of the queue, just remove the split(",") part (it's already done). This
does not add anything to the critical path - the split must be done anyway.
Now, instead of building a fake string "B,cannedobject" and uncanning on
the other side, you can simply put a tuple in the queue ("B", the_object)
and just get the object on the other side. If I'm not misunderstanding
your problem, I think this is the cleanest way to do that.
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
