This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
You're using the Service Locator pattern. That's pretty much the opposite of how JSF is designed - it's based on Inversion of Control.
So generally the proper way to get a bean instance in JSF is to simply code a setter method to inject that bean into the target bean and wire the bean in JSF using the ManagedPropetry feature. This will allow you to connect the 2 beans together without making the target bean JSF-specific.
An IDE is no substitute for an Intelligent Developer.
The primary benefits of IoC are that are that you don't have to design the bean for a single platform. Instead, you design them as POJOs and let the platform itself manage them. This contributes to code reusability and enhanced testability, since POJOs can be unit-tested in isolation without setting up a complicated runtime environment and can also be wired into testing systems such as mock systems without requiring error-prone source code changes.
Using a service locator, on the other hand, by definition mandates some sort of platform-specific specific location mechanism, which makes it a lot harder to do such things.
Performance should not be a consideration. JSF as a whole is going to totally swamp the the overhead of connecting beans. If you're considering stuff like that in the design of a system, you're almost certainly committing the sin of premature optimization (we hold regular penance sessions over in the Java Performance Forum). And if it's true that a few extra microseconds are going to kill you, you shouldn't be using JSF at all.