Anton Korobeynikov

> I ran it on a system with 16 GBytes of RAM, and I saw the memory usage of p4c increase to between 11 and 12 GBytes, and I think...

> That seems like a crazy statistic in general. Either the inliner calls ResolveReferences hundreds of times or the pass is just slow. It former. Here are some stats: overall...

One of factors that contribute is quite severe, I'd say. Essentially, portion of all the time is spent in `ISimpleNamespace::getDeclByName()`. Which in turn is just `IndexedVector::getDeclaration`. `IndexedVector` stores declaration name...

It seems that `ActionsInliner` does some updates of `ReferenceMap` (using `SubstituteParameters`), but it seems it is not enough. @mihaibudiu @ChrisDodd Do you remember any details here?

> I am not sure what "is not enough" in the above statement means. Well, here is the comment in `substituteParameters.h`: ``` // When a PathExpression is cloned, it is...

> You can now look up references in the current context of any visitor, by having tbe visitor inherit from P4::ResolutionContext and then calling any of the various resolve methods...

> > So, looks like we'd need in some cases to still use refMap for name generation. > > For name generation, you can use the MinimalNameGenerator pass/object instead of...

> but I never got it completely working. One issue that I already found is that `ResolveReferences` has implicit and very subtle assumption to be mixed into `Inspector`. `TypeInference` is...

Some very preliminary results from downstream test. Before: ``` ________________________________________________________ Executed in 87.54 secs fish external usr time 134.23 secs 0.26 millis 134.23 secs sys time 2.08 secs 3.87 millis...

> Are these gains specifically because of inliner optimizations or changes to the refMap/`getDeclByName`? The whole idea is to sunset refMap entirely. The speedup above is obtained by switching to...