From: Sam S. <sd...@gn...> - 2003-02-28 17:24:04
|
> * In message <m3y...@lo...> > * On the subject of "Re: [clisp-list] parse-integer slowdown & make-string /= make-array of 'character" > * Sent on 28 Feb 2003 11:14:56 -0500 > * I write: > > > * Honorable "Hoehle, Joerg-Cyril" <Joe...@t-...> writes: > > > > It also appears that MAKE-STRING is very different from MAKE-ARRAY > > :element-type 'character. Using strings from MAKE-STRING is fast with > > PARSE-INTEGER, while strings from MAKE-ARRAY exhibit the tremendous slowdown. > > On 2002-05-22 Bruno introduced mutable small strings. > This means that whenever you parse a string, you call > unpack_sstring_alloca(), which involves a copy_16bit_32bit() or > copy_8bit_32bit() call for a "small string" (8-bit or 16-bit). > > It appears that we need to eliminate all calls to > unpack_sstring_alloca() and replace them with SstringDispatch(), > which does not carry the same overhead. Unfortunately this carries a different kind of overhead: code size (triplicating the code). Another things is that many functions take chart[] arguments, and they will have to be triplicated too! An alternative would be to introduce a struct chart_vec_t { char* ptr; /* the int vector */ size_t byte_size; /* (log (/ sizeof(elt) 8) 2), i.e. 0 for 8, 1 for 16, 2 for 32 */ } and then pass it instead of chart[] and then access element like this: struct chart_vec_t cv; #define CV_REF(cv,ii) (int)(*(cv.ptr+(ii<<cv.byte_size))) I am not a C performance expert, so I need some input here - what is the best way to go? -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Sex is like air. It's only a big deal if you can't get any. |