[Openmcl-devel] string handling question

[Hamilton Link]

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.

h


> Soo... what I'm really looking for is a clue about how OpenMCL handles 
> strings and what the best way
> to deal is. I know about UVREF, %SUBSTR, DOVECTOR and a few others - 
> any more pointers would
> be appreciated.
>
> :alex
>
> On Nov 9, 2004, at 4:36 PM, Andrew P. Lentvorski, Jr. wrote:
>
>>
>> On Nov 9, 2004, at 7:36 AM, alex crain wrote:
>>
>>> For example,
>>>   (FIND #\s "mystring")
>>> eventually boils down to
>>>   (dovector (a "mystring")
>>>                     (when (eq a #\s) (return a)))
>>> but some implementations of strchr are smarter then that and would 
>>> do things in 4 or
>>> 8 byte chunks.
>>>
>>> Since I'm working on an OpenMCL editor, implementation dependence is 
>>> not a problem.
>>
>> Personally, I really would not walk this path.
>>
>> Unless you preload the cache with the constant string, the time 
>> required to pull that string from main memory will more than dominate 
>> the time to loop over it for small string lengths.
>>
>> In addition, a generic loop unrolling optimization would be useful to 
>> OpenMCL, in general.  Although, it may already exist for certain 
>> levels of optimization.
>>
>> What is the larger context problem that you are trying to solve?
>>
>> -a
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>