There remains Alexei's worry that this is likely to substantially slow down all applications. I think his worry related to my initial suggestion for doing this at construction time. I think that just adding a member function implementing its own cache shouldn't add overhead to applications not using it. (The only difference would be the constructor having to initialize the cache to NULL).
Well, any patch would have to go into Pynac, in order to be of advantage in Sage. Pynac is a fork of GiNaC. (In the past, we've repeatedly fixed Sage bugs in GiNaC and suggested patches for Pynac and vice-versa, but that doesn't mean that changes in GiNaC propagate automatically into Sage. At least I'm not aware of that.) Thanks for pointing that out; I was under the impression that Pynac was a Python wrapper for Ginac. I might just have to look at Pynac
2012/8/14 Richard B. Kreckel <kreckel@ginac.de>: then. Do you happen to know what the reason was for forking?
I would normally think that it would be a method of ex (and basic). Where would you say the cache lives if it where a global function? It should be possible to equip that global function with a static hashmap ex -> symbols. Of course, that opens a memory leak because the map is never cleaned up. So, as an alternative, one could maintain that map only while it can really speed up things: store it in an object and delete it when that object is destructed. There would be no memory leak if the cache were to live in the object.