> Given that there is a transition tree for maps, why does the engine not realize that there is one map (for objects with a single property a) that is valid for both objects? In other words, why does the engine cache the most specific applicable map instead of the most generally applicable map in this case?
Checking whether the object's map exactly matches some pointer is very fast. Traversing the transition tree to find out whether the object's map derives from some other map could be very slow, depending on how many layers of tree must be loaded along the way. Unfortunately, there's currently no simple and fast way to detect that a map is a member of a large group of maps that have some matching properties. This behavior is indeed troubling, and occasionally I write design documents with wild ideas for improving the situation. Like this one <https://docs.google.com/document/d/1UTMBym8HUgRsT5F53_h6ulAZL2X6hU088w7MiDu4Jn4/edit?usp=sharing> from a couple of months ago (which I never shared til now), or this other one <https://docs.google.com/document/d/1j9uXBT_wudNjM1wobHt2KxxjwwgRcAjsTNs5y_0GwpM/edit?usp=sharing> from 2019. I know that other people have also given serious consideration to scenarios like the one you described, but the current behavior remains, mostly because the megamorphic stub cache <https://benediktmeurer.de/2018/03/23/impact-of-polymorphism-on-component-based-frameworks-like-react/#scalability-issues> is pretty good, so meaningful improvement is hard. > I'm currently writing a parser, and to work around that limitation I'd need to write this code! The code you wrote is one option; another option would be to put all type-specific data inside a nested object, like so: { nodeType: 'IfStatement', data: { test: ..., consequent: ..., alternate: ... } } That way, all Node objects match precisely and have just the two properties 'nodeType' and 'data'. > that example code was gibberish Looked fine to me 🙂. > Thus while there is megamorphism it is not likely to be dominant in the total costs of real execution. That seems logical, but I'll plagiarize from Ryan again: "moreso than in other systems, you need to measure measure measure measure, and make sure your measurements are as near as possible to the real thing you're trying to build." Best, Seth On Sunday, May 22, 2022 at 7:28:51 AM UTC-7 [email protected] wrote: > Sorry that example code was gibberish. I'm so used to being able to edit > posts I make (and use syntax highlighting) that I'm very sloppy. The > correct example code was: > > function buildIfStatement(test, consequent, alternate) { > return { > type: 'IfStatement', > prop1: test, > prop2: consequent, > prop3: alternate, > prop4: null, > prop5: null, > } > } > > But actually I think it was utterly pointless code as it misunderstands > the real impact of the problem. Ast-handling code tends to look like: > > function print() { > switch(node.type) { // <-- only this access is needlessly megamorphic > case 'IfStatement': return 'if (' + node.test + ')' + ... // <-- this > access is monomorphic > } > } > > Thus while there is megamorphism it is not likely to be dominant in the > total costs of real execution. > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/fccfa44b-da3d-4be7-a607-98f85dce551an%40googlegroups.com.
