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

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Fri Feb 28 01:30:08 2003

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.

---

From: Sam Steingold <[email-masked]>
Date: Fri Feb 28 06:55:07 2003

> * In message <[email-masked]>
> * On the subject of "[clisp-list] parse-integer slowdown & make-string /= make-array of 'character"
> * Sent on Fri, 28 Feb 2003 10:28:54 +0100
> * Honorable "Hoehle, Joerg-Cyril" <[email-masked]> writes:
>
> All I need now is to get a Linux box here with internet access
> rights. None of the machines here has, for now. 

why can't you do that with woe32?

> 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.

compile with "-p" (add it to CFLAGS manually)

-- 
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>
Just because you're paranoid doesn't mean they AREN'T after you.