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 el@laramies.com wrote:
- 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.