Does TikZ clipping remove invisible elements to reduce the size of the output PDF?

Question

Consider the following code

\documentclass{article}
\usepackage{tikz}
\begin{document}
\begin{tikzpicture}
  \clip (1,1) rectangle (9,9);
  \foreach \x in {0,...,10}
    \foreach \y in {0,...,10}
      { \draw (\x,\y) circle (1mm); }
\end{tikzpicture}
\end{document}

When compiled with pdfLaTeX, this gives a PDF file of 15 KB. Now let's change the number of circles (the new circles are outside the clipping area):

\documentclass{article}
\usepackage{tikz}
\begin{document}
\begin{tikzpicture}
  \clip (1,1) rectangle (9,9);
  \foreach \x in {0,...,50}
    \foreach \y in {0,...,50}
      { \draw (\x,\y) circle (1mm); }
\end{tikzpicture}
\end{document}

This gives a PDF which takes 139 KB. So the question is

Q: What does the clip command do with the content outside the clipping area? The above experiment suggests that all the circles are in fact there, but some of them are invisible. Is the clipping made on the side of the PDF viewer or on the side of the compiler? And is there a way to optimize the result by means of TikZ? If no, how should one proceed?

Answer 1

If your question is about TikZ itself, then here is a simple test

\documentclass{article}
\usepackage{tikz}
\begin{document}

\message{^^J^^J break point A ^^J^^J}

\tracingmacros1
\begin{tikzpicture}
    \path(0,0)(10,10);
    \clip(1,1)rectangle(9,9);
    \foreach\x in{0,...,10}
        \foreach\y in{0,...,10}
            \path(\x,\y);
\end{tikzpicture}
\tracingmacros0

\message{^^J^^J break point B ^^J^^J}

\tracingmacros1
\begin{tikzpicture}
    \path(0,0)(10,10);
    \clip(4,4)rectangle(6,6);
    \foreach\x in{0,...,10}
        \foreach\y in{0,...,10}
            \path(\x,\y);
\end{tikzpicture}
\tracingmacros0

\message{^^J^^J break point C ^^J^^J}

\end{document}

I ended up with a 347858-line log file. And then I compared the two parts, finding that the only difference is about the clipping path itself, not what follows. So we may conclude TikZ does not do any clipping-reduction. It is other bottom drivers that can do the optimization. (They may or may not, you see the results vary in comments)

To be more explanative, a \clip inside TikZ is first equivalent to \path[clip], and then translate to an encoded path followed by an operator (e.g. \pgfusepath{clip} or W). TikZ then shipped-out these stuff and forget it. In general, we cannot expect TikZ to do the optimization using its poor arithmetic.