OS X on PPC. Compilation flags are -O3 -fomit-frame-pointer -fno-strict-aliasing -mcpu=7450 -DC_ENABLE_PTABLES.
I will try on my x86 box later. On 11/24/05, felix winkelmann <[EMAIL PROTECTED]> wrote: > On 11/24/05, Zbigniew <[EMAIL PROTECTED]> wrote: > > Here's another interesting performance note, and I assure you > > everything is compiled this time. > > > > I have a C function which returns a void * by reference (i.e. it takes > > a void ** as argument). I was using let-location, but I found that if > > you pass a #<pointer> object as a scheme-pointer, it works just as > > well and is about twice as fast. > > > > Okay, now the interesting part. In numerous places, such as tcp.scm, > > a string object is allocated and passed as a scheme-pointer so it can > > be filled. This is the same as taking my #<pointer> example above and > > changing it to (make-string 4), assuming 32 bit pointers. > > > > What I found is that replacing (##sys#make-pointer) with (make-string > > 4) incurs a huge number of garbage collections and is slow. What's > > more, using (make-byte-vector 4) does NOT have this problem! I have > > no idea why, as the implementation looks nearly identical to me > > (basically, ##sys#allocate-vector). These results are repeatable for > > me. > > > > On what system are you running this? On a x86 Linux box the > string-based version is actually running faster than the byte-vector > based one. > String-allocation may result in some waste of memory, since strings > are 8-byte aligned, byte-vectors are not. But the allocation difference > in your case is quite substantial, which is odd. > > > cheers, > felix > _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
