Assuming that your script is going to be able to produce some output immediately, and then some more after some delay through DB access or similar?

Depending upon the type of formatting of your HTML, some (most?) browsers will be able to start to render the page from the partial output from the early prints therebye giving the user a feeling that things are happening. This can be advantagous.

If you save it all up and print it all in one go, it may result in a longer delay before the browser starts to render something, which may cause the perception of a slower site than they might otherwise have.

This effect is particularly noticable when rendering large volumes of data in tables. If the rows are sent in separate chunks--and if the sizes of the cells are predefined--then most browsers will be able to render the table in chunks, rather having to wait for the whole table to arrive before being able to render anything.

This is one of those cases were perceived performance is probably more important that absolute performance.

Thanks duff and BrowserUK, I think i will go for "print small chunks" sulution even if it will give me the better abs. performance, because in my case the data is really a huge table (which probably could be rendered partially).

The best way to find out is to profile the code to see which satisfy your optimality criteria. Which you haven't specified BTW. The first may be slightly slower but may also use less memory. What are you trying to optimize?

However, the first question that comes to my mind is "Why do you care?" Premature optimization is the root of all evil. The best thing to do is separate your program logic from your presentation logic, so you should really be using some sort of templating system. Most templating systems take care of handling the output for you so you don't have to worry about doing it piecemeal. :-)