[Openmcl-devel] string handling question
alexcrain at mail2.widgetworks.com
Tue Nov 9 22:22:19 UTC 2004
My larger problem has to do with working with strings in general.
I'm adding features to hemlock and COCOA has a penchant for wanting to
look at all the attributes of
all the characters in the buffer on a regular basis. COCOA takes care
of all kinds of display issues,
which is nice, but there is no easy way to say:
"Look, this is a fixed width font and I only modified line #6, so you
really don't have to look at the entire
buffer to see if anything else has changed."
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.
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
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?
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel