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
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:
typeExprNode = 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
typeExprNode = 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.
The text was updated successfully, but these errors were encountered:
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:
...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
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 ofRc<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, andRc
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.The text was updated successfully, but these errors were encountered: