Full disclosure - I am an old person who was trained in a different pre-Internet available at work era. I've watched the skills of the younger developers steadily deteriorate mostly due to them not retaining information or understanding the solution they grabbed from the Internet. I've observed that the level of competence a person had after 1-2 years of experience, 20 years ago, is now the level of competence someone has after 5-7 years of experience. (Yes that is a personal observation but I've done a lot of hiring, I have no statistical data on the matter and yes, I am sometimes old and cranky, take this statement with a grain of salt. And stay off my yard.)
Looking up everything is inefficient in terms of time. It also is a symptom of someone who doesn't have much depth of knowledge. People with depth of knowldge can write code faster than people who don't know how to solve a problem without looking things up. So it is worth it to learn to handle more things without having to look things up continually.
Now I'm not saying you should never look things up, I'm saying you should learn to retain knowledge and only need to look up things you use rarely or when you encounter a genuinely new issue or language or paradigm. And I'm not saying you shouldn't be reading to keep up with new solutions and tools and languages.
My real concern with developers who look up things too often that that too many of them (not necessarily you) never develop the analytical skills to understand the problems they have and the solutions that are needed. Read how many questions there are where the person puts in the error message that he or she clearly doesn't understand, but which should be quite clear to anyone operating at the professional level. Or the ones where the person says, "it's not working, why?" with no reference to the error message or how it isn't working and the code is syntactically correct. Or the ones who are given a piece of code that should work, but in the haste to answer first the person has made an obvious syntax error (like say missing the ON keyword in a SQL join to use an example I saw just today) and the poster comes back with I get an error on line 12. Why yes, if you look at line 12 it obvious what the error is if you have baseline competence.
So if what you are looking up is stuff that is part of the core functionality of the language(s) (BTW this should include SQL if you are accessing databases) you have used for more than six months, I suspect you are looking up too much. If what you are looking up are advanced features, especially those you might use rarely, then you are doing fine.
But how to you learn to retain more information? First understand why the code broke. Even if someone gives you a working solution, if you don't see why that worked and yours did not, then ask. If you don't understand the error message then ask what it meant and then try to solve it yourself.
And never cut and paste a solution you don't understand. In fact, don't cut and paste at all. If you want to retain information, you need to do the typing of it. Actually physically writing the code yourself helps you learn it. That is a well-known learning technique.
Practice generalizing your understanding of the code. I've seen people ask similar questions over and over again over time because they don't understand that the solution they got a month ago to problem ABC is the same solution to the new problem DEF.
So when you've researched something, take some time to think about what types of problems it would be good for solving and write yourself notes about that. Then when you have a problem to solve, first check your own notes to see of you have already noted a possible technique. If you evaluate multiple ways to solve a problem, take notes on the type of problem, the possible solutions you looked at and the pros and cons of each one. Again the note taking is helping solidify the knowledge in your brain, you already have your own thought process in terms of the pros and cons worked out and don't have to do that again (or at least not in as much depth, you may still look for more possible techniques) for the next similar problem.
And when deciding what to learn next, go for some depth in one of your main technologies before jumping into learning the first 30 days worth of yet another technology (this assumes you have enough breadth of knowledge to actually perform your job, if you need to use 6 technologies - get the basics in all six first before going for depth). Then go back and forth, learning new stuff, at a basic level, learning something in more depth, then learning more new technologies at a basic level. If you do this over time, you will find that your basic level of what you want out of a new technology is much deeper because you understand more advanced questions to ask about it.
Another way to learn to retain knowledge is to teach it to someone else. Answer questions at places like this, present training topics to your team, make presentations at your local user groups, write blog entries and help maintain a wiki of information at your company to help other developers.