Re: [Chicken-users] A more detailed plea for help with FFI...

[Ed Watkeys]

On Dec 15, 2004, at 12:14 PM, felix winkelmann wrote:

> > Is your "use finalizers conservatively" policy about performance or
> > correctness? (That's not necessarily an either-or question.)
>
> [...] Use finalizers when they fit the job, but excessive use of them 
> will decrease performance (chicken-specific) [...]

What sort of overhead is associated with a finalizer call, compared to 
a normal GC operation? For example, if I created a string library that 
malloc'd memory (in C), and free'd it via a simple function installed 
via set-finalizer!, how would that compare to Chicken's built in 
strings? So, in other words...

(let ((chicken-string "This is a test."))
      (foreign-string (make-foreign-this-is-a-test-string)))
        #t)

Putting aside the fact that a sufficiently intelligent system could 
optimize this down to #t, how do chicken-string and foreign-string meet 
their ends? As soon as I get back from lunch, I'll write a couple 
programs that create and destroy a million native chicken-string and 
foreign-string instances and compare the run times.

Speaking of optimization, would knowing whether a foreign function has 
side effects allow any Scheme compiler written in the next (umm) ten 
years produce better code? Straying even farther afield, what's your 
take on the whole dynamic recompiling VM approach vs. static compiling? 
As a Mac old-timer, I remember dealing with the 68K -> PPC transition, 
Apple's 68K interpreter, and their subsequent DR 68K interpreter. 
Everyone seemed to forget about that just in time for Sun to "discover" 
the same approach and  use it in their HotSpot JVM, which -- I've read 
-- can beat optimized, compiled C code thanks to the dynamic analysis 
of the code. And then there's Transmeta, but I'm not an x86 guy, so I 
never paid that much attention.

Digressingly,
Ed

--
Watkeys Product Design * http://watkeys.com/
address@hidden * +1 215 694 4201