A tome like SICP takes time to get through it, and I think it's more because of the way our brain functions more than anything else.
My strategy when working through the book was to slowly chip away at it, sometimes non-sequentially, and let the ideas slowly stick. When I say, non-sequentially, I mean to say that I would look at all the chapters, think about my current knowledge base, and then try to attack as many chapters at once.
Many will disagree with this style of learning, and the initial confusion lasts longer than I'd like, but eventually, all the thoughts just suddenly click.
That said, SiCP was a totally different beast, where the knowledge had to be accumulated and used throughout the book.
I think the most efficient way, would be to read each chapter multiple times first, trying to get key ideas (not everything) to stick.
Then proceed on to the problems, but set a time limit for each problem. Seriously, this book is so huge that one will never get all the problems done (i haven't, but that's part of the plan). Go search for some answers to easier questions, tackle those of roughly the same level of difficulty, then move on to more difficult questions, never obsessing over the fact that you couldn't solve a problem.
Because many of the ideas are one step removed from "everyday programmer", investing heavily (you be the judge) in the problems alone won't be worth it.
The best thing that I did however, was to "leave some questions in the tank" and re-read chapters at fixed intervals (say on every Monday), and attempt problems that I previously needed assistance to solve.
Oftentimes, I realise that I managed to solve it far more efficiently and with much cleaner code (and am constantly surprised by the difference in code quality compared side by side). Rewriting code in a different language also helps (eg: I'm doing Project Euler in python and Common Lisp)
Finally, I think you'll enjoy the journey much more if you pace yourself and give it at least a year to work it's magic.