Hi,
Great work!
A thought on the API – could frame_init perhaps be removed from the “public”
API and have frame_setup_from_* perform that internally instead (and return the
new frame)? That way a frame cache could be introduced transparently later on,
by having frame_setup_from_* perform cache lookups based on the object/function
offset etc. instead of creating a new frame.
Yes, caching multiple frame entries sounds desirable. If the cache is
placed/referenced by the parent frame, even a multi-level cache should be
possible:
void fie(int i) { }
void bar(int i) { fie(i + 1); }
void foo() { foreach(enumerate(1000000), int i) bar(i); }
Here, the F_FOREACH handler could set a PIKE_FRAME_DO_CACHE flag in the current
frame, which would enable caching of the “bar” call. But the flag could also be
propagated to the child frame, so that the “fie” call is cached in the frame
handling the execution of “bar”. When execution leaves the scope that initiated
the caching, the caches should be cleaned up recursively. I’m not sure whether
this would work from a practical standpoint, but it might be worth considering.
Thoughts?
/Marty
> On 12 Apr 2016, at 18:48 , Arne Goedeke <e...@laramies.com> wrote:
>
>
> 4)
> - Use the new API in more places like filter and automap.
> - I also really like your idea of caching the last frame. I was
> thinking about something similar, except that I did not think of using
> the frame for that, but instead cache it globally. Also, in many
> situations it is actually not enough to cache only one frame, instead we
> need 2 or more:
>
> foreach (foo; mixed key; mixed val) bar();
>
> During one iteration, this calls both next() in the iterator of foo and
> bar(). Its probably a good idea to experiment with that.
>
