Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Freezing overload resolution for performance. #588

Open
ninnghazad opened this issue Jan 4, 2022 · 1 comment
Open

Freezing overload resolution for performance. #588

ninnghazad opened this issue Jan 4, 2022 · 1 comment

Comments

@ninnghazad
Copy link
Contributor

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?

@stellarpower
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants