lines of code is too rough measure of code. Certainly long convoluted code can often be improved by shortening it, but at the same time short obfuscated code can often be improved by lengthening it.
The critical thing to understand is that the length of the code is actually a symptom in this process, the primary concerns are symmetry (fairly objective) and readability (fairly subjective) and finally performance (objective)
Any time you improve code by shortening what you are actually doing is exploiting some symmetry in the code. I.E. two or more bits of code are doing something which is the same in some way, they may be completely different in other ways, but if you can separate out the code which is the same you can remove the duplication.
This is inherently subjective however generally people agree that longer descriptive names are better than shorter ones. Less specific, more general code can use shorter more generic names as there is less to describe, but any time you have a specific meaning specific naming helps.
after you have looking at the clarity of your code the next question is is it fast enough? At design time you can look at complexity of structures & algorithms and hopefully prove that you are at least in the right ball park. To fully answer the question though you need to measure the implementation. Only if the measured performance is not good enough is it worth going back to optimize your bottlenecks.