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

Optimize type comparisons #435

Closed
Razican opened this issue Jun 1, 2020 · 1 comment · Fixed by #441
Closed

Optimize type comparisons #435

Razican opened this issue Jun 1, 2020 · 1 comment · Fixed by #441
Assignees
Labels
E-Easy Easy enhancement New feature or request good first issue Good for newcomers performance Performance related changes and issues
Milestone

Comments

@Razican
Copy link
Member

Razican commented Jun 1, 2020

Current situation
Currently, if the interpreter wants to know what type a value is, it has to call get_type(), which returns a &str, and compare it to another &str. This takes a pretty log time.

It would be much faster to just compare values in an enumeration, which should be at most 1-word size, and can therefore be stored in the stack easily.

We sill need the &str version of the type, though, since for example, the typeof operator needs to display it. I think the best option would be for the Type enum to implement a function called as_str() so that we can get the &str value if needed.

So, the idea is to have a Type enum, that is returned by the get_type() function here, and then, that enum to have an as_str() function with a similar code to the current function.

@Razican Razican added enhancement New feature or request good first issue Good for newcomers performance Performance related changes and issues E-Easy Easy labels Jun 1, 2020
@Lan2u
Copy link

Lan2u commented Jun 1, 2020

I'll give this a go

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-Easy Easy enhancement New feature or request good first issue Good for newcomers performance Performance related changes and issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants