[clisp-list] parse-integer slowdown & make-string /= make-array of 'character

[Hoehle, Joerg-C. <Joe...@t-...>]

Hi,

From the description of ENCODING as a type in impnotes, I came to realise that
	(MAKE-ARRAY x :element-type charset:iso-8859-1)
must be perfectly legal (in CLISP), according to the ANSI CL wording.
[769]> (subtypep charset:iso-8859-1 'character) -> T ; T

Yet
[573]> (sys::string-info (make-array 1 :element-type charset:iso-8859-1))
8 ; NIL ; NIL
[579]> (sys::string-info (make-array 1 :element-type charset:unicode-16))
8 ; NIL ; NIL
I'd have expected 16 here.

I'm unsure whether CLISP should implement and advocate this as a recommended way to obtain the string-8/16/32 objects that CLISP internally uses.

Yet it looks like the right way (TRW) to allocate a string specialised to hold unicode-16 or -32 or -8 characters (or iso-8859-1 etc.).

Maybe somebody would find a use out of this (instead of these differences being shamefully hidden as by now, causing unexpected conversions)?

(Which brings me back to encoding-zeroes and rambling about encoding_min/max broken slots.)


Sam wrote:
>> 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.

>try SYS::STRING-INFO on the different strings.
[558]> (sys::string-info (make-string 1))
32 ; NIL ; NIL                                                                         
[559]> (sys::string-info (make-array 1 :element-type 'character))
8 ; NIL ;NIL

Oh, I mixed up the output from SPACE in my previous post -- sorry.
SIMPLE-STRING                0         0          1    130008
is from MAKE-ARRAY, and 520008 is from MAKE-STRING. So MAKE-STRING takes more room but is faster with PARSE-INTEGER.

>> What changed between 2.28 and 2.30, producing such a dramatic impact?
>2002-05-22 mutable small strings.
Ah. Yet that does not explain why parse-integer changed run-time behaviour while other functions didn't (at least I didn't notice).


>could you please profile your code with the CVS head?
That'll have to wait until I can use CVS. It's less of a problem now that cvs-ssh.sourceforge.net has opened a ssh server on port 443 so as to fool all those firewalls or proxies which would limit htts access to port 443 only.
All I need now is to get a Linux box here with internet access rights. None of the machines here has, for now.

Please explain how to profile with CLISP -- you probably don't mean the metering.lisp package. I once added profile(3) calls to C code but I see no support in makemake or configure of CLISP from that.

Regards,
	Jorg Hohle.