[vtkusers] string compare bug?

[David.Pont at ForestResearch.co.nz]

Nothing to do with the possible bug, just something <=2c worth,
  To speed up the case where two very long strings are different can you
first compare string lengths? Ie if the lengths are different the strings
are different, which should save some time in that case. Where the lengths
match then the full compare is needed.
Another trick, which is no use as a general approach, but can be used in
specific applications:  If long strings typically carry a prefix which
changes slowly, and a suffix which changes more rapidly, it can be much
more efficient to do your own compare (when the lengths are equal) by
comparing chars starting from the end and advancing towards the front of
the string.

  regards
     Dave Pont



|--------+--------------------------------->
|        |          Kevin Wright           |
|        |          <krw at viz-solutions.com>|
|        |          Sent by:               |
|        |          vtkusers-admin at public.k|
|        |          itware.com             |
|        |                                 |
|        |                                 |
|        |          08/10/2002 10:32       |
|        |                                 |
|--------+--------------------------------->
  >------------------------------------------------------------------------------------------------------------|
  |                                                                                                            |
  |      To:     vtkusers at public.kitware.com                                                                   |
  |      cc:                                                                                                   |
  |      Subject:     Re: [vtkusers] string compare bug?                                                       |
  >------------------------------------------------------------------------------------------------------------|




At 05:13 PM 10/7/2002 -0400, you wrote:
>>>Are you using vtkSocketController/vtkSocketCommunicator?  These objects
>>>already do this under the hood.
>>>-Jeff
>>
>>
>>No, I'm tying it in with some other code here.  Are you saying that
>>vtkSocketController/Communicator addresses the bug that I'm talking
>>about, or that it provides the same functionality?
>
>
>those classes provide the same functionality, and use a very similar
>approach.  I'm not sure what you are seeing is a bug per-se - does your
>Irix/Linux build do the same thing?  I agree that the string compare could

>be expensive, but the dataset update could be even more so.  I have been
>told that the data readers/writers are going to change in the near future
>to xml anyway, but it would be good to know if this is just a windows
>problem.  I have been using the socketcommunicator for quite some time and

>it doesn't exhibit these symptoms.  If you have some sample code, it might

>be worth putting up on the list so people can test it...
>-Jeff

I'm going to be doing some testing on IRIX/LINUX and if there are any
interesting results I'll post them.  I think its entirely possible that the

vtk socket code does demonstrate the same symptoms.  As I said, for some
reason, it only happens when the incoming polydata only changes slightly
from the version currently in the reader.  It would be difficult to extract

the code that I'm seeing this on, but perhaps I'll try to make a small
sample that exhibits the same symptoms.

As far as the cost of the string compare, it seems to me that by uploading
the responsibility of that check to the caller of the reader, you give the
programmer the option to either spend the time checking, or not.  In my
case, I'm performing that check already before sending the data down the
socket, so its purely wasted time for me.  Its a small point, but perhaps
even a "no check" option would be a good addition to the reader.

Thanks for the feedback Jeff.

Kevin.




>>Kevin.
>>
>>
>>>Kevin Wright wrote:
>>>
>>>>I just tracked down what looks like an odd bug, and I was wondering if
>>>>anyone out there had any insight.
>>>>
>>>>I'm using a vtkPolyDataReader object to field incoming polydata
>>>>definitions through a socket.  I do this by reading the polydata from
>>>>the socket into a string, then using the input string in the
vtkDataReader.
>>>>
>>>>Everything generally worked fine, except in some cases the pipeline
>>>>would not update when new data came down the socket.  Eventually I
>>>>tracked the problem down to vtkDataReader::SetInputString which, before

>>>>assigning the string, does a string compare between the old and new
string.
>>>>
>>>>When the new and old datasets were very similar (usually identical
>>>>geometry, slightly changed scalar values) the strncmp would return a
>>>>match.  The string length was correct, and once the string compare was
>>>>removed, everything worked fine.
>>>>
>>>>I'm working on a Windows 2000 machine with VC++ 6.0.  I'm about to try
>>>>the same thing on IRIX and Linux to see what happens, but I was
wondering:
>>>>
>>>>1. Has anyone seen this kind of behavior before?
>>>>2. Should the string compare really be there at all, given that these
>>>>strings could be very long?
>>>>
>>>>Regards,
>>>>Kevin.
>>>>
>>>>_______________________________________________
>>>>This is the private VTK discussion list. Please keep messages on-topic.

>>>>Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
>>>>Follow this link to subscribe/unsubscribe:
>>>>http://public.kitware.com/mailman/listinfo/vtkusers
>>
>>
>>_______________________________________________
>>This is the private VTK discussion list. Please keep messages on-topic.
>>Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
>>Follow this link to subscribe/unsubscribe:
>>http://public.kitware.com/mailman/listinfo/vtkusers
>>
>


_______________________________________________
This is the private VTK discussion list.
Please keep messages on-topic. Check the FAQ at: <
http://public.kitware.com/cgi-bin/vtkfaq>
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtkusers