Reviews are undeniably important. I've spent a far above average time on this problem when I was on the dev team for CodeCollaborator so I feel qualified to suggest:
a) its a code review, not an author review
b) be respectful of your reviewer's time:
1. 200 lines is a big review obligation, 500 lines should be a hard maximum. Remember that boilerplate code does have meaning, and it counts. If you can't make time for reviews, then don't rubber stamp, just don't review.
2. Run whatever automation and analysis is available to you before submitting for review, and fix what it tells you to fix or note the trigger and document why its a false alarm.
3. You may count unit test code at 1/3 the normal rate, and even get 50 lines totally free. This relieves the burden of mentally running your code, and makes it easy to request additional test cases, which will be easier on your ego than bugs.
All the big problems people have with code reviews are about checking your ego, respecting your peers, and clear communication.
