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

Reducing Clones of Exprs #22

Open
ExpHP opened this issue Apr 9, 2021 · 0 comments
Open

Reducing Clones of Exprs #22

ExpHP opened this issue Apr 9, 2021 · 0 comments
Labels
internals This is about internal APIs or code style

Comments

@ExpHP
Copy link
Owner

ExpHP commented Apr 9, 2021

During some other recent attempts to change some things, I've had to clone an unseemly number of Expr nodes, sometimes even at multiple levels of depth (i.e. parents and children, which could have quadratic cost). In hopes to make those changes more palatable, I recently tried introducing this type into the AST:

type ExprNode = Rc<Sp<Expr>>;

...but met with some nastiness in the AST-gen macros, which were designed on the principle that Sp<_> always wraps around AST nodes.

I shelved it for now, but when I pick it back up I should probably try

type ExprNode = Rc<Expr>;

and use Sp<ExprNode> around the AST instead, despite the heavier footprint.

Arenas?

Arenas could be even cheaper than Rc<_> performance (we would be copying &'ctx Expr instead of Rc<Expr>), but they have a massive cost in terms of complexity of implementation due to the lifetime parameter it would place on AST nodes.

Our big performance bottleneck is still File IO; the only justification even for the switch to Rc<_> is just as a preventative measure, and Rc ought to be "good enough" for the forseeable future. Therefore I don't think there's any reason to give any serious thought to arenas yet.

@ExpHP ExpHP added the internals This is about internal APIs or code style label Apr 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internals This is about internal APIs or code style
Projects
None yet
Development

No branches or pull requests

1 participant