[Chicken-hackers] Re: [Chicken-janitors] Re: [Chicken-bugs] #356: inline recursion

[felix winkelmann]

On Dec 4, 2007 2:16 AM, Elf <address@hidden> wrote:
>
> i consider it an extremely serious bug.  i have run into it in at least 4
> separate libs or programs ive written, and theres no real way of knowing that
> its inline-looping infinitely instead of merely taking a long time.  the
> general cases where this has happened: some requirement for high efficiency,
> some relatively small number of small external-interface procedures,
> some relatively large number of very small procedures called exclusively
> by each other or some relatively small number of very large procedures called
> exclusively by each other, either a dispatch-return or a subloop using
> the same set of procedures, and a single entry point between inlined and
> non-inlined procedures.  it sounds a lot more complex than it is.  the
> current raw-sockets implementation in the funk repository ran into this 
> problem
> in several versions.  etxtproc (formerly eformat, not yet working in the eggs
> repo) ran into it with essentially state machine transformations.  the current
> workaround that ive used to get around the problem is to encapsulate potential
> problem procedures in letrecs.... this only solves the self-loop case, 
> however.
>

I guess we are using inline procedures differently... It should make much of
a difference whether you call large procedures inline or not. Actually this is
a job that should be handled by the compiler (inlining normal procedures).
define-inline is useful for small pieces of code that call mostly primitive
operations.

> HOWEVER! this is a comparatively minor optimisation compare to some of what
> we should be paying attention to, so simply putting a compiler warning and
> changing the one inline to non-inline would be more than sufficient in the
> short term.  gc and number handling improvements would be orders of magnitude
> more useful :)

What kind of improvements would you suggest?


cheers,
felix