Php Output - A bit at a time VS all at once.

[WyCnet]

Debate time:

In another thread laserlight can be quoted as claiming:

I don't think it is a terribly good idea to be printing vast swaths of HTML code directly from a PHP script though. The tight coupling remains even if it looks like it "seperate(s) the Php processing and the Php output".

I disagree with the bit at a time output. For one a programmer cannot get a grip on how long a Host takes to fully process a script, and secondly there is no clear idea of transmission times to the browser, if one so wishes to calculate these numbers.

On another note laserlight may be thinking of implicit output of "HTML text", when the text is outside the Php tags, as opposed to explicit output of text using the echo statement. In the implicit output scheme much care has to be taken to avoid white space output, whereas in the explicit scheme the whitespaces can be seen on inspection.

As such I find it quite advantageous to "echo" explicitly everything I want on my Browser page.

I am inviting laserlight to defend his position using the advantage/disadvantage method, or any other method.

[bradgrafelman]

WyCnet;11007173 wrote:

I disagree with the bit at a time output. For one a programmer cannot get a grip on how long a Host takes to fully process a script, and secondly there is no clear idea of transmission times to the browser, if one so wishes to calculate these numbers.

From what I can recall, I don't think the quote had anything to do with processing time or anything like that... more like a separation of business logic and display/presentation logic/code. In that matter, I agree with laserlight. For example, I keep as much HTML out of my .php scripts as possible (or, at the very lest, confine it to specific PHP scripts that are solely dedicated to outputting data).

WyCnet;11007173 wrote:

On another note laserlight may be thinking of implicit output of "HTML text", when the text is outside the Php tags, as opposed to explicit output of text using the echo statement. In the implicit output scheme much care has to be taken to avoid white space output, whereas in the explicit scheme the whitespaces can be seen on inspection.

The "care" has to be taken regardless of whether it's outside of <?php .. ?> tags or inside of an echo string, thus I don't really understand the point you're making here. (Then again, repeated/extraneous whitespace is pretty much ignored in HTML, so there's really no reason to care much about it anyway.)

Again, though, this isn't much of an issue I run into regularly since I try to make sure my PHP scripts contain mostly... PHP. Not dabs of it interspersed with HTML (or vise versa).

[laserlight]

WyCnet wrote:

I disagree with the bit at a time output.

If you are printing lots of HTML code a bit at a time directly from a PHP script, then you have the same disadvantage of tight coupling except that it is even worse.

WyCnet wrote:

For one a programmer cannot get a grip on how long a Host takes to fully process a script, and secondly there is no clear idea of transmission times to the browser, if one so wishes to calculate these numbers.

I don't see how this has any bearing on the discussion as there will be script processing time and network latency either way.

WyCnet wrote:

On another note laserlight may be thinking of implicit output of "HTML text", when the text is outside the Php tags, as opposed to explicit output of text using the echo statement. In the implicit output scheme much care has to be taken to avoid white space output, whereas in the explicit scheme the whitespaces can be seen on inspection.

Ah, but now we get to the central idea of separation of concerns: the idea here is that the PHP script does processing, and the result is combined with some kind of template to render the final output. This way, one team member can work on the PHP script, another team member can work on the HTML (e.g., he/she is also the web designer/front-end web developer). PHP could very well be the template language, but the point is that the person doing the clientside code does not have to wade through a PHP script to do that editing, and the PHP developer does not have to worry that "care has to be taken to avoid white space output".

[Weedpacket]

bradgrafelman wrote:

For example, I keep as much HTML out of my .php scripts as possible (or, at the very lest, confine it to specific PHP scripts that are solely dedicated to outputting data).

In the same way that I keep as much SQL out of my .php scripts as possible. I don't want to tie my PHP applications to any one particular output medium any more than I want to tie it to any one particular DBMS.

If changing the client interface from Flash to HTML5, say, involves anything other than generating output (creating widget/document templates into which the content will be injected) or user response parsing, then something needs fixing with the application's design (it's not resilient enough). Seeing "SELECT...." and "<a href...." in the same file is a red flag.

[WyCnet]

bradgrafelman;11007175 wrote:

...
Again, though, this isn't much of an issue I run into regularly since I try to make sure my PHP scripts contain mostly... PHP. Not dabs of it interspersed with HTML (or vise versa).

Therefore you disagree with bit-at-a-time.

[laserlight]

WyCnet wrote:

Therefore you disagree with bit-at-a-time.

So do I, but if you want to focus on "bit-at-a-time versus all-at-once", then you're missing the point: that whether you are printing HTML code little-by-little with echo statements throughout the script, or just in a few places with heredoc, you still have your presentation tightly coupled with the logic.

[WyCnet]

laserlight;11007177 wrote:

...
I don't see how this has any bearing on the discussion as there will be script processing time and network latency either way.

What do you mean? I am saying Php prcesssing to calculate variables including Datanase lookups, get relevant CSS and Javascript suport routines, processing to fill the templates, and then release the output to the Browser. Where is the Network latency that occurs either way? The transmission times I wish to calculate start when the output is sent to the browser, so if you do bit-at-a-time, unless you use buffering, transmission begins while the script is still being processed.

[WyCnet]

Weedpacket;11007185 wrote:

In the same way that I keep as much SQL out of my .php scripts as possible. I don't want to tie my PHP applications to any one particular output medium any more than I want to tie it to any one particular DBMS.

If changing the client interface from Flash to HTML5, say, involves anything other than generating output (creating widget/document templates into which the content will be injected) or user response parsing, then something needs fixing with the application's design (it's not resilient enough). Seeing "SELECT...." and "<a href...." in the same file is a red flag.

Yes these cover the poinrs I am trying to defend, which shows clearly the seperation of responsibilities.

[Weedpacket]

It seems you're not understanding laserlight's position, then, since mine is the same as his. Or we're not understanding yours.

If it's about the relative efficiency; my own experiments and experience say that output of chunks of significant size tends to result in smoother performance as output passes through all the buffering and packeting that lie between the program and the client machine; but that the difference in behaviour isn't significant enough to dictate program design. As for the choice of which of the five quoting mechanisms is preferred, the impact on program performance is microscopic, and vanishes next to the effective difference in maintaining source code.

[johanafm]

WyCnet;11007199 wrote:

Where is the Network latency that occurs either way?

One large or ten smaller echo statements will both suffer from a crappy network connection.

WyCnet;11007199 wrote:

The transmission times I wish to calculate start when the output is sent to the browser

Other than specifically for measuring how long time it takes all of the content to get transfered, how does this matter? You have to send it all to the user wether you do it at once or in separate chunks. This measurement may be relevant if you need/want to reduce bandwith use or increase over all transfer times to the end user. But for the end user, what matters is time from request to load completion, rather than ignoring initial processing before the first outpout is sent.

WyCnet;11007199 wrote:

, so if you do bit-at-a-time, unless you use buffering, transmission begins while the script is still being processed.

... which pretty much any web server will use. And once again, how does it matter. The connection is allready made and the client is simply waiting for a response.

Weedpacket;11007185 wrote:

In the same way that I keep as much SQL out of my .php scripts as pos
sible. I don't want to tie my PHP applications to any one particular output medium any more than I want to tie it to any one particular DBMS.
If changing the client interface from Flash to HTML5, say, involves anything other than generating output

Weedpacket;11007203 wrote:

but that the difference in behaviour isn't significant enough to dictate program design.

And this is why they tell you separation is important. Separation means easier maintenance. It's easy to switch layout if all you change is a template or even a CSS file, since you don't have to wade through logic to do so. It's easy to switch from one DBMS to another if your SQL code, connection management etc is kept apart from all other code, such as one or a few base classes that deals with general storage and retrieval and one class that talks to the database, rather than chaning a ten lines on every single script file.
When (or rather "if ever") you get to a point where chunked output or all-at-once output would have such an impact that it is needed for whatever reason, it would make sense to deal with that at this point since it's both unlikely and a lot easier to achieve - If you allready have decent separation as described by LL and Weed.

Weedpacket;11007203 wrote:

the impact on program performance is microscopic, and vanishes next to the effective difference in maintaining source code.

... while effectiveness in maintaining source code reduces cost a lot, which also enables you to buy more expensive hardware should performance be needed since it will be cheaper in the long run than programming work hours. Furthermore, if you are concerned with efficiency, code separation is once again a good first step since it's then easier to profile and fix slow and or unscalable sections of code.

[bradgrafelman]

WyCnet;11007199 wrote:

The transmission times I wish to calculate start when the output is sent to the browser, so if you do bit-at-a-time, unless you use buffering, transmission begins while the script is still being processed.

Who says transmission will begin as soon as you start outputting a little data? As has been mentioned already, most webservers do (and should) use some sort of buffering.

Plus, with the overhead involved with TCP-based communications, sending 20 packets each of size 15 bytes is probably going to take longer than sending a single 300-byte packet.

[WyCnet]

johanafm;11007209 wrote:

One large or ten smaller echo statements will both suffer from a crappy network connection.

It matters, because Service Providers have high speed connections, and at least one or two slower speed connections. What this means is when traffic is high, the high-speed connections get more turns at the multiplexer/demultiplexer, router, than the others. So if a Browser User with a slower connection has a few small packets in the queue at peak hours, latency will be much greater, than a full packet of information. Service Providers wil not hold on to your packets if the queue is empty, which is what happens during off-hours, so Users enjoy high-speed connections during that time.

[WyCnet]

bradgrafelman;11007217 wrote:

Who says transmission will begin as soon as you start outputting a little data? As has been mentioned already, most webservers do (and should) use some sort of buffering.

Ok. I once thought that was the case and I believed that Php buffering was created to circumvent it, now it seems that Php buffering may have been created to implement it, but why?. However I am not confused.

Yet why would laserlight say:

"I don't think it is a terribly good idea to be printing vast swaths of HTML code directly from a PHP script though.",

I mean if you are not printing vast swaths of code, what are you printing? Medium swaths, or small chunks of HTML?

[Weedpacket]

Laserlight says (emphasis mine):

I don't think it is a terribly good idea to be printing vast swaths of HTML code directly from a PHP script though.

For the above quote's context, see this thread. It was in response to a post by WyCnet which contained the following:

<?php
$newTITLE = "A new coding style";
// do my processing here and create the variables whose values users will see on their browsers

$myHTMLpage = <<< ENDstring
$docTYPE
<html>
<head>
$outputCSS
$outputSCRIPTS
<title>$newTITLE</title>
</head>
<body>
$pageProduced
</body>

</html>

ENDstring;
echo $myHTMLpage ;
?> 

And laserlight didn't like the idea because

The tight coupling remains even if it looks like it "seperate(s) the Php processing and the Php output".

[NogDog]

I guess my main thought here is to be careful about eschewing generally perceived best practices in the name of what may be premature optimization. While [nearly] consensus best practices such as having the output layer separated as much as possible from the control and data laters are good starting points, it's always possible there may be exceptions to that rule for certain edge cases, such as unique performance requirements. You need to balance cost of implementation and, perhaps more importantly in many cases, maintenance, versus what may be very tiny performance gains that make your code more tangled and difficult to maintain. Also, if you are going to increase your app's complexity and thus decrease its maintainability for the sake of performance, you had darned well better have some solid empirical evidence that the [performance] ends justify the means (and resultant costs).

We run a pretty data-intensive app at work sitting on top of a MVC-style PHP framework (modeled on Java Struts), where [nearly] all output is via Smarty templates which are invoked at the tail end of the process. It works just fine that way. The vast majority (if not all?) of the time there are any sort of performance issues, it's in the data layer -- and most of those are eventually optimized away in the data layer. That is where we spend developer time finding significant performance tweaks, not worrying about which type of string quoting is used and the myriad of other things PHPers often argue about for saving a millisecond here and a microsecond there.

Of course, we have several servers running off a load-balancer; but these days hardware is cheaper than developers. 🙂

Anyway, I guess what I'm saying is to choose your performance battles wisely. Deal with the big performance issues first to get the most bang for your developer buck, and don't sweat the tiny stuff -- that's what your hardware budget is for. 😉

[laserlight]

WyCnet wrote:

I mean if you are not printing vast swaths of code, what are you printing? Medium swaths, or small chunks of HTML?

Refer to my post #6. The reason why I wrote "vast swaths of HTML code" is because that is usually where separating clientside code from your PHP code shines as frontend developers are likely to become involved. If you are just printing a small amount of HTML code for testing purposes or for a utility script that will only be tweaked by PHP developers, then printing HTML code directly from a PHP script is perfectly fine, but then in such a case interspersing echo statements in the code is not terribly bad either.

My reaction is to your portrayal of heredoc with an entire HTML document as a best practice, i.e., you rightly stated:

WyCnet wrote:

Things look good to you on a test page, but real pages have to be sophisticated and the best way to retain sophistication is to have the ability to maintain HTML pages as the times change while you target a new audience.

But the method that you proposed is only a step better, not the best practice to achieve that. Now, if you had suggested the heredoc method as the next step for oxide01 to take, that would be a different story, but the statement "I would advise anyone writing modern Php to use Heredocs" certainly does not convey that idea, but rather makes it seem like you are recommending a best practice.

[WyCnet]

Hello all, I am starting to believe we all concur with functionality seperation as an ideal technique. I am showing a practical example from one of my code sources. Note the easier ability to code the onload statement when the Heredoc quoting system is being used.

...
$producer=<<<ENDs
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.1 Transitional//EN">
<meta http-equiv=Content-Type content="text/html;charset=UTF-8">
<head>
$output1
$output
</head>
<body class=dBP onload='WyCdictionaryLookup(document.getElementById("WyCdictionary"));addLegend()'>
<div id="WyCdictionary">
start
</div>
<div id="legend" class="legend">
legend
</div>
<div id="vdiv" class=text>
diction
</div>
</body></html>
ENDs;
echo $producer;
exit;
?>

It is true that developers have their own styles based on their programming experiences, however my thoughts were directed to those writing Php from scratch, implying that including Heredocs in their Knowledge will lead to easier Php coding.

[Weedpacket]

What does the [font=monospace]...[/font] in your code hide? If it's the same as what you elided as

// do my processing here and create the variables whose values users will see on their browsers 

in your previous sample then you still need to explain what this "processing" you're talking about is, because that is where the issue originally raised lies.

Why don't you write

...
echo<<<ENDs
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.1 Transitional//EN">
<meta http-equiv=Content-Type content="text/html;charset=UTF-8">
<head>
$output1
$output
</head>
<body class=dBP onload='WyCdictionaryLookup(document.getElementById("WyCdictionary"));addLegend()'>
<div id="WyCdictionary">
start
</div>
<div id="legend" class="legend">
legend
</div>
<div id="vdiv" class=text>
diction
</div>
</body></html>
ENDs;
exit;
?>

WyCnet wrote:

Note the easier ability to code the onload statement when the Heredoc quoting system is being used.

Not really. For one thing, I prefer to avoid using "on*" attributes in HTML pages in the first place. For another: in my preferred mechanism, if anything in a page were dependent on external resources, the object responsible for generating that page would be querying its components to identify those dependencies, resolving them, and inserting the appropriate declarations in the appropriate manner into the output stream. In short, get the program figure out what's supposed to go in the page (assuming it is a page) where. (Going further along those lines will have me repeating parts of how I interact with designers and what ends up happening to their Photoshop mockups and wireframes).

Not what someone just learning PHP would write, but that's not what you're arguing: you're arguing that Heredocs makes programming easier. The rest of us just see it as another quoting mechanism.

[johanafm]

WyCnet;11007389 wrote:

It matters, because Service Providers have

NogDog;11007407 wrote:

I guess my main thought here is to be careful about eschewing generally perceived

Exactly my point of view NogDog. Somewhere earlier I said something about that "when/if" you have performance issues which warrant a specific approach (e.g. such as not using separation of logic from layout if that would actually mean a performance gain which I doubt) that's when you start doing it, not before. Using scalable algorithms on the other hand is usually a good idea to do to begin with since they will otherwise quickly deteriorate performance, while using them usually will not at all hinder maintenance. Anyway, in your above statement you once again say something as if it's a set rule rather than a common guideline for some user scenarios or even possibly common user scenarios (where user is you/your service, not your end users): "Service Providers have".

Our service providers doesn't have anything like that, at least not for us. I don't remember if we used to pay for 50Mbps max (with allowance for limited peaks above it) and raised the roof to 100Mbps after we introduced video upload and streaming, or if we went from 100 to 150 Mbps. It doesn't matter how or when our end users connect to our servers, they will get their stuff. If we surpass the "peak limit" (which isn't really a limit) everything still works as before. But should we start pushing our average above it or even staying above it for extended periods of time, we'd have to renegotiate our deal with them.

As for large chunks or not, as pointed out several times, the last by Weedpacket's emphasis, as well as implicitly by NogDog's mention of how they user Smarty templates: Seprate program logic from layout and output. You can still output everything at once if you wish. Or if you have can't get around processing for a long time (from user perspective) do as little as you can to give them a decent amount of stuff sent to them in the logic layer, then user the layout/display layer to send that stuff to them (in one large chunk) so they know something is happening, eventually followed by one or more large chunks. Not to speed things up or slow them down, but to provide users with what they need to feel satisfied.

As for Smarty, I've heard PHP developers complain about it being slow, and we also use it for one community site with 2k - 10k concurrent users around the clock running on 3 web fronts (and still managing on one should needs be), and never have had any issues with Smarty performance.
- Writing optimized SQL is an issue (data layer)
- Keeping proper DB indexes is an issue (data layer)
- Memcaching the right stuff to reduce DB load is an issue (data layer)
- Caching parts of pages using smarty to reduce load on the DB (and memcache although that's not the point here) is an issue (data layer)
- Preprocessing ads every so often to keep them cached on disk rather than doing the work on every page request is an issue (data layer)

Smarty works fine. Its performance is no issue. Wether we send pages in one go or in chunks doesn't matter. And also note that we can still use Smarty (template enging) without achieving separation of data layer and program logic from display. Smarty is one way of facilitating the separation, but you can do it in any number of ways. And even with tools to facilitate that separation, you can still "achieve" not seprating them if you don't know how to or if you really wanted not to.

One single large output doesn't really have anything to do with anything else. Just like separation of logic and layout has nothing to do with anything else.