Page 2 of 2

Posted: Thu Jul 14, 2005 10:55 am
by Deemo
it seems that the selecting isnt really a problem either. I commented out the line that checks is the task is supposed to be selected and it goes just as slow

few things i had in mind:
A) could the fact that im using OOP with several objects lead to slowness?
B) is foreach itself slow? would i be better off using a good old for loop?

Posted: Thu Jul 14, 2005 10:59 am
by pickle
OOP could be slowing it down a little, but I noticed you're directly accessing the object variables, not using accessor methods. Directly accessing object variables shouldn't really hurt your performance (although in your case it might be - something's obviously slowing it down).

Try extracting the necessary data from the objects once, before your loops, and put the data in an array. Then, use the foreach to loop through that new data array. That way, you'll only need to access the objects once.

Posted: Thu Jul 14, 2005 10:59 am
by patrikG
Simply for simple profiling: remove the if-clause containig the "select" bit. Conditionals can a bit of a bottleneck.

Posted: Thu Jul 14, 2005 11:17 am
by Deemo
i reordered it a bit like pickle suggested and it cut down 3 seconds from the normal time. so thanks alot for telling me to do that

heres my next problem, and its kind of weird. In IE, this script takes 2 seconds. In Firefox it takes 10. What i noticed is that IE shows a blank screen and then displays everything at once, whereas firefox takes its time displaying everything one by one. Is this just the way the browsers work? i hate to make something that only works well in IE

Posted: Thu Jul 14, 2005 11:23 am
by pickle
Ya, that's the difference in browsers, although a 5X rendering time difference is a little extreme. Call ob_implicit_flush() at the top of the script which dumps the buffer to the stream automatically after every output call - Firefox would them dynamically display the page as it's created.

Mind posting the code again so I can see what you did? I'm curious.

Posted: Thu Jul 14, 2005 11:34 am
by Deemo
i did the ob_implicit_flush() and it made no difference. But now that you mention implicit flush, i remember turning implicit_flush to On in my php.ini file for my debugger program to work.

Heres the new code that i have:

Code: Select all

//Way up in the beginning of the script 
$advisorlist = Advisor::getAdvisors();
//by doing this, i also took out 2 queries that basically did the same thing

//Later on 
for ($i = 1; $i <= $cfg['numMaxAdvisors']; $i++)
{
  foreach ($advisorlist as $tempkey =>$tempvalue)
  {
    $options .= '<option value'".$tempvalue ->mID."';
    if ($task ->mAdvisors[$i - 1] ->mID == $tempvalue ->mID)
      echo " selected";
    $options .= '>'.$tempvalue ->mName.'</option>';
  }
}
echo $options;
Doesnt seem too much different, frankly i have no idea why this works faster. all i really did was move some arrays around (not seen in this code). I think it does have to do with the OOP a bit though.

im really confused about this whole business :roll:

Posted: Thu Jul 14, 2005 12:27 pm
by wwwapu
You mentioned this outputs 2150 lines of HTML. Looking at the picture it seems like <table>. How many <tr> you have in the <table>?.

Firefox tries to parse tables row by row (or tbody by tbody ?), which is helpful when loading big tables as you don't have to wait long to get something to see. If your table is huge it becomes very slow and irritating.

Opera handles huge tables quite well, have you tested with it? This can partially be a problem with browsers table capabilities.

I tested these with about 400 <tr> <table> with each <tr> like this:

Code: Select all

&lt;tr&gt;&lt;td&gt;&lt;select&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;/select&gt;
	&lt;td&gt;&lt;select&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;/select&gt;
	&lt;td&gt;&lt;select&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;/select&gt;
	&lt;td&gt;&lt;select&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;option value=&quote;jajajalka&quote;&gt;lkdsfdsk&lt;/option&gt;&lt;/select&gt;
	&lt;/tr&gt;
IE6 showed this in about 10-15 sec, but hung once, Firefox 1.04 took its time about one minute and Opera 8 did everything almost immediately.

Posted: Thu Jul 14, 2005 12:53 pm
by Deemo
is there any way to get artound this in firefox? maybe some about:config setting you can change?

one more thing (god the problems just keep stacking up). I was stress testing the program, and at around 200 rows it takes about 10 seconds to refresh in IE. That is definetely not sufficient, so there are still big problems with my code.

I think the best way i can help you guys help me is to better explain exactly what my code does so bear with me

it starts by importing 3 class files, 1 theme file and 1 config file. It then calls pageHeader from the theme file to display the tables up to a specific point where my program then takes over. I then use different $_GET variables to set up my query, which as a default is "SELECT ID FROM Tasks WHERE Done=0 ORDER BY DueDate,Client,Priority ASC"

then run the query and store all the rows in a 2 dimensional array. Then i enter into the "Master for loop", a foreach loop that goes through every single row and displays the data. But it does more than just simple displaying, it calls a method for each entry it has to display. This method adds some more HTML tags to allow editing on site without visible text boxes. Then it closes the row and moves onto the next one. This row contains 4 drop down menus. Each drop down menu has 6 or 7 options in it, and has to go through each one to determine which one has to be selected by default (its not the same every time). This closes the last row.


Now i dont know whether this is normal or not, but the end result of the HTML is 38063 lines of HTML and an execution time of around 9-15 seconds with a database made up of 331 rows of data. Is that good?

Posted: Thu Jul 14, 2005 1:12 pm
by wwwapu
Do you really have to display all rows on one page? If not then 'pagination' is the search term which could be useful.

Posted: Thu Jul 14, 2005 1:52 pm
by Deemo
i think that may be the only real solution i have to this, unfortunately, my client wont be too happy but hey, cant do the impossible :?

Posted: Thu Jul 14, 2005 2:25 pm
by pickle
Deemo wrote:Now i dont know whether this is normal or not, but the end result of the HTML is 38063 lines of HTML and an execution time of around 9-15 seconds with a database made up of 331 rows of data. Is that good?
That certainly seems reasonable. That 9-15 seconds, is that time between inital page access, and when you can view the page or is it time to generate the page?

Either way, the only way to speed that up would be to get a faster server or a faster desktop.

One thing you might want to try if you have the time is XMLhttp. It should allow you to do pagination without it actually looking like it.

Posted: Thu Jul 14, 2005 4:49 pm
by Deemo
that time is from when i hit f5 to when everything pops up


as for XMLHTTP, i was looking into putting that in future versions but i need to get this done soon

Posted: Thu Jul 14, 2005 4:56 pm
by pickle
Do some timing then, using microtime() to see how much of that time is in PHP, and how much is in the browser, rendering the HTML.

Posted: Thu Jul 14, 2005 5:44 pm
by McGruff
If you want to time scripts you really need to use Xdebug. The profiler reports on op code compiling as well as script execution - script parsing can be getting on for half the total.