I've never run into this problem, so my answer below is only theoretical.

Even in a large app with 40 or 50 pages, you would be unlikely to have 40 or 50 singletons. The reason is that in GetIt you usually define them as lazy singletons. That means they don't even get loaded into memory unless you visit the part of the app that uses them. How often do people visit every page of a large app? Not often. Also, there's no reason to register something as a singleton if you don't need to maintain some sort of state. You can register your state management class as a factory and then you'll start with fresh state every time you visit the page. Alternatively, you could store the page state some other way (shared preferences, for example) and then restore that state when you come back. Finally, GetIt allows even singletons to be deregistered when you don't need them anymore. For all of these reasons, I don't think it's likely that the singletons are going to be a performance or memory problem.

In my opinion, the more important issue is simplicity and understanding. I prefer to use a state management system that I can understand. I like that better than a magical solution that is theoretically fast but is hard to use.

Another piece of advice that I've often heard repeated is don't prematurely optimize. That is, don't worry about performance in the beginning. If performance issues come up later, you can look at potential causes and solutions at that time. The Flutter DevTools can help with that.

That said, I'm not trying to talk you into using this solution. I think you should learn a few different ways to manage state. I just think it's unnecessary to be overly worried about performance issues related to singletons.