You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I remember that when talking about ChaiScript performance the dynamic overload resolution was mentioned as a bottleneck, and how caching it would be cool but unfeasible seeing how stuff can be invalidated and so on.
I was wondering if it was possible to conceive of a way to "freeze" the overload resolution and then cache it.
As in, i load and execute a bunch of scripts - setting stuff up, then freeze it and doing kind of static resolution, building a fast index of overloads or something. If i add stuff after that one may have to rebuild that manually or make do with a LIFO way of ignoring overloads and just go by name.
Thoughts?
The text was updated successfully, but these errors were encountered:
I was also thinking along these lines. I can't remember my exact train of thought, but something like whether the symbols could be loaded into a table, invalidated any time a new module was added, and if this simplified the lookup.
I am also wondering how much dynamic type information is used/required. I'm new to Chai, so I may not be correct in some of my thinking here. But the overload resolution is needed in Chai to support what is a core feature in C++; for C++, the compiler selects the best overload at compile-time and inserts the symbol, so naturally, more complex processing is required to try to emulate this at runtime for Chai. However, if I understand correctly, Chai is not quite dynamicall-typed; variables are untyped until their first assignment, and then we get operator= any time we try to assign, which is what we expect. Therefore, it would seem that it ought to be possible to choose the best overload to be dispatched at the point the call is evaluated in the AST, irrespective of the runtime state of variables in the script. I.e., something like Python or Ruby, must check on each line as it goes that the object provided has the given properties, as it's totally possible that a reference has been re-assigned to an unrelated type, and this may or may not possess the required capabilities for duck-typing. Whilst with Chai, once the initial assignment has been made, it ought to be the case that this type remains for the lifetime of the object in the script, so I'd have thought this could participate in overload resolution, before the script is evaluated proper.
If performance would be improved, and it would be possible (and I've not neglected anything significant here), I would imagine resolving overloads once when the script is parsed, based on the semi-static type of the variable, would be sufficient to provide overloading as we are used to - i.e., it's a compile-time feature based on static types. Does Chai have enough information to do this? If we call into a C++ function, we should I thik know the return type, so is this someting that Chai can infer at parse-time, or only when it encounters the line again at execution?
I remember that when talking about ChaiScript performance the dynamic overload resolution was mentioned as a bottleneck, and how caching it would be cool but unfeasible seeing how stuff can be invalidated and so on.
I was wondering if it was possible to conceive of a way to "freeze" the overload resolution and then cache it.
As in, i load and execute a bunch of scripts - setting stuff up, then freeze it and doing kind of static resolution, building a fast index of overloads or something. If i add stuff after that one may have to rebuild that manually or make do with a LIFO way of ignoring overloads and just go by name.
Thoughts?
The text was updated successfully, but these errors were encountered: