Of course, as @Jake mention, the readability of the code is the most important thing. So this should always be enforced!
However, the question is quite an interesting one. I might have an analysis answer. I use the pdflatex compiler, version: 3.1415926-2.4-1.40.13
First we have to determine which minimal example to look into.
\documentclass{article}
\usepackage{tikz}
\pdfcompresslevel=0 % allows direct comparison
\begin{document}
\thispagestyle{empty} % this is crucial to obtain the smallest file
\end{document}
Furthermore, there are two codes being compared, we will compare the object streams created in the PDF by our pdflatex executable (i.e. TikZ shipout).
I only show what is important for the drawing, object stream operations above and below the region of interest are the same.
Code
\begin{tikzpicture}
\draw (0,0) --(1,0) (2,0) -- (3,0);
\end{tikzpicture}
Produces the following page object:
0.0 0.0 m % start point of new drawing (m for move)
28.3468 0.0 l % line ending (l) for line
56.69362 0.0 m % new move
85.04042 0.0 l % draw line
S % stop
Code
\begin{tikzpicture}
\draw (0,0) --(1,0);
\draw (2,0) -- (3,0);
\end{tikzpicture}
Produces the following page object:
0.0 0.0 m % start point of new drawing (m for move)
28.3468 0.0 l % line ending (l) for line
S % stop
56.69362 0.0 m % new move
85.04042 0.0 l % draw line
S % stop
So as seen above the two-segmented code actually does produce extra work for the PDF viewer.
Lets consider a slightly more interesting example:
Code
\begin{tikzpicture}
\draw[red] (0,0) --(1,0) (2,0) -- (3,0);
\end{tikzpicture}
Produces the following object:
1 0 0 rg 1 0 0 RG % choose color in RGB
0.0 0.0 m % move
28.3468 0.0 l % draw
56.69362 0.0 m % move
85.04042 0.0 l % draw
S % stop
0 g 0 G % apply color
Code
\begin{tikzpicture}
\draw[red] (0,0) --(1,0);
\draw[red] (2,0) -- (3,0);
\end{tikzpicture}
Produces the following object:
1 0 0 rg 1 0 0 RG % choose color
0.0 0.0 m % move
28.3468 0.0 l % draw
S % stop
0 g 0 G % apply color
Q % restore the previous saved graphics state
q % save the current graphics state (i.e. Q q is a no-op)
1 0 0 rg 1 0 0 RG % choose color
56.69362 0.0 m % move
85.04042 0.0 l % draw
S % stop
0 g 0 G % apply color
However, as you notice, the compression of the PDF will reduce this to roughly the same layout as it is easy. :)
Lets, suffice to say that whatever you do, the optimization routine in the final product is endlessly more important than these simplistic examples.
Conclusion
The object stream must be created in some way, before being optimized, so this would mean that less bytes to pass to the optimizer should (in theory) mean a faster compilation (provided the optimizer is linearly dependent on the number of bytes received!).
But it is easy to consider very complex drawings with a lot of no-op operations in the non-compressed file. And also, the easier the object stream is to interpret by the optimizer, the more optimized it will be, producing smaller files.
Dare I say: it could be argued that one should do everything on one path.
EDIT
I wanted to clarify whether there actually was a speed penalty associated with using several path-segments. So here is what I did.
- The above examples with the red color have been used for testing.
- In my
test.tex document I create them 10.000 times
- I time this over an average of 100 runs
And here is what I get:
-----One draw Two draws
Mean 20.3028 26.6568
Std. 1.2976 2.5581
So clearly, it does have an effect on the execution time, but here we have used 10.000 and 20.000 draw commands. respectively. So the document has to be on the order of this for it to be noticeable. The difference in std. makes me wonder whether this is clear comparison. However, I will probably not do the test again. :)
pdffile on my system. – Andrew Swann Mar 10 '13 at 12:33standaloneclass andtikzpackage loaded. – percusse Mar 10 '13 at 12:41tikzpictureenvironment only increased the difference by 1 extra byte total. – Andrew Swann Mar 10 '13 at 12:41pathcommand if they're very closely related. You can't have different colours within a singlepathcommand, for example (unless you useedgecommands). I think that the verbose syntax of TikZ is actually one of it's strong points: It's very easy to read and understand. Trying to shorten the code at the cost of readability seems like you're optimising for the wrong objective. – Jake Mar 10 '13 at 12:45\pdfcompressionlevel=0produces notable differences. – Andrew Swann Mar 10 '13 at 13:19