[Openmcl-devel] string handling question

[alex crain]

On Nov 10, 2004, at 11:14 PM, Hamilton Link wrote:

>
> On Nov 9, 2004, at 3:22 PM, alex crain wrote:
>
>> COCOA is really unbright about inferring things and will often scan 
>> the entire file for changes after
>> I insert a single character, which means *lots* of string processing 
>> and good optimization or the
>> system grinds to a halt.
>
> Hold on, I thought we got past this problem already. The system was 
> pokey for a while there, but we added a couple of function definitions 
> and it became plenty fast enough. Is there a performance problem 
> again? Premature optimization is the root of all evil, man. I'd be 
> happy to see a slowish working version of the code with all the new 
> features. Do we have that and I just haven't updated lately or have 
> you not yet released that? If the former, my bad. I'll test it out and 
> see if it runs fast enough. If the latter, let's get the release out 
> and worry about fast enough when I/we can see what works.

We did get past that problem, when Gary dug around and found 
getCharacters:range: vs. getCharacters:.
Then I started playing with character attributes, and even though I 
used the same trick, ie attributesAtIndex:effectiveRange: vs.
attributeAtIndex:, I'm still stuck with cocoa asking the same stupid 
questions over and over again.

It finally dawned on me that if cocoa was asking the same questions, I 
could just cache the answer and avoid
recomputing the answer every time (YES! He can be taught!) So it's all 
moot at this point.

I also started declaring everything, which should inspire the compiler 
to use the fasted possible forms.

I still feel like I could learn something, though (hint, hint). My 
research into strings led me to a couple of postings by
Gary earlier this year that describe uvectors and their related forms 
in detail (very nice). I'm interested in any other
OpenMCL specific forms that can be used to optimize code in a 
straightforward way. One of the problems that I've
run into with cocoa is that some of the methods are time sensitive - if 
you spend too much time doing edit processing,
for example, cocoa and/or hemlock may attempt to edit the buffer while 
it is being worked on which pretty much
hoses that thread. I'm not sure if it's a cocoa thing or a bridge thing 
but I have no problems if I keep the processing time
to a minimum.

:alex