Why do ob_* pre-rendered pages seem to take just as long to create as the pulls of the elements directly?

[Q695]

example:

pulling a 5x5 array of data from a database

 

time differences:

components (unbuilt):13400101661682

elements (built):13817119598389

 

How I'm stealing the elements from the PHP code:

ob_start();

...

ob_end_clean();

[trq]

dum de dum.

[Q695]

dum de dum.

I'm sorry, I don't speak that language.  I asked the guy who spoke at the apps at the speed of thought meetup in the MPLS area, and he said I was doing the right thing to run faster.

[ginerjm]

We, apparently, don't speak your language.  What the h... are you talking about?  Do you have a question, a problem, a reason for this post?

[Q695]

Un-rendered: the object has yet to be built by the server from individual pulls.

Rendered:you can do one pull, and less calculations to write something out as it's stored in the database as an object.

 

Why do they seem to take the same amount of time?

[requinix]

Simply adding output buffering doesn't magically make the rest of the code execute quickly. I have no idea what this "rendered" stuff is but output buffering only helps if you're doing lots of small writes.

[CroNiX]

All the output buffering does is send the output once everything has been processed instead of "real time"...or "linearly, as processed". They really should take about the same time for the end user to receive both. The same calculations, as you put it, would take place in both scenarios. The only difference using buffered output is the users browser receives the entire document at once instead of like sending the header, waiting for something to be processed and then sending that out. So instead of the page being "drawn" in chunks, it's all done at once.

[Q695]

So rendering the items into a database object doesn't automatically make the page run quicker, if you're dumping the buffered data into a database as well as dumping it to the screen?  The rendered item is essentially turning 25 pulls into 1 pull from the database.

 

The rendering is turning page small chunks into fewer bigger page chunks thus you need 1 instead of 25 looked up.

 

I'm using one database (small chunks) to populate another database (big chunks) to make the pages run quicker.

Edited October 2, 2014 by Q695

[mac_gyver]

it sounds like you are running database queries in a loop, which is extremely inefficient, since the time taken to communicate the characters making up each query from php to the database server is several times longer than the amount of time most data retrieval queries actually take to run.

 

what sort of problem are you having that you are trying to solve?

 

if you are having a performance problem, the only way of fixing it is to target the problem. the only things that will have a major effect are things that significantly reduce the amount of processing being done or of reducing the total amount of data being manipulated/transferred. output buffering does neither of these things, and in fact it increases the processing time by a very slight amount since php must manage the buffering of the output.

[Q695]

it sounds like you are running database queries in a loop, which is extremely inefficient, since the time taken to communicate the characters making up each query from php to the database server is several times longer than the amount of time most data retrieval queries actually take to run.

 

what sort of problem are you having that you are trying to solve?

 

if you are having a performance problem, the only way of fixing it is to target the problem. the only things that will have a major effect are things that significantly reduce the amount of processing being done or of reducing the total amount of data being manipulated/transferred. output buffering does neither of these things, and in fact it increases the processing time by a very slight amount since php must manage the buffering of the output.

 

I'm trying to build a 3d table map of what you can see from where you are on the map of elements assigned to their individual <td> (the shell for every terrain square).

 

I'm trying to make the page a lot faster than looping per row/column.

 

Each data "byte" will be slower to look up individually then every bit contained in a "kilobyte" having its own reference on the database somewhere in no particular order.

[mac_gyver]

we cannot really help you without knowing what you are specifically doing. that would take seeing enough of your code and some sample data to be able to reproduce the content.

 

but the subject of this thread, output buffering, would have no noticeable affect on server-side or client-side performance. the only possible affect output buffering would have if you have a TON of html markup (several 10's or 100's of K bytes) on the page and you are using compression (gzip) in conjunction with output buffering on the server and decompressing it in the client to save on the transmission time between the server and the client.

 

this would only save on the transmission time. if you do have a TON of html markup, it must still be rendered in the browser, so it can still take a long time for the page to be displayed, even if your server-side code and the transmission time have been optimized.

 

have you in fact profiled the times taken for everything so that you know where the greatest amount of time is being taken so that you know where to concentrate your effort in optimizing the process?