Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I have this Perl CGI program and I allow the user to select the number of data to view on this HTML table. I go through a foreach ... foreach ... and print each row.
There is an issue with the Perl CGI script when it prints over 3,000 rows of data and my Firefox window becomes unresponsive. I am also linking dataTable jquery.
What approaches can I do to prevent freezing of browser window?
Most likely, the browser window freezes due to resource consumption on the browser when displaying a large table; and has nothing to do with your back-end Perl CGI code.
The easiest way to confirm that is to append a log-print statement (e.g. print to STDERR) to the very end of your CGI script and print the timestamp; then you run the script and look at your web server logs to see when the script completed. Almost certainly, you will find it has completed very fast.
Another (though less reliable) indicator that it’s the browser that is the bottleneck is observing consumed memory and CPU in your favorite process management program on your OS (TaskManager/ProcessExplorer/ps/top)
Now, as far as the problems with the browser display, Wrikken gave some good suggestions. Avoiding complicated event handling (including jQuery stuff) on a very large table is a Good Idea if you can; use classes instead of IDs where possible.
Some others would be:
Use pre-defined pixel width for all columns (and ideally all rows for the bargain). Browsers work a lot faster when rendering a table when they don’t have to compute this on the fly for every row.
Consider switching to DIV based table instead of TABLE. To be honest I don’t know if that would help speed wise or not – it’d be a good SO question or better yet, try it and benchmark. It may not be a philosophically pure solution for presenting tabulated data though.
As Wrikken said, paginate. No user can process a 3000 row table efficiently even if it printed blindingly fast, so actually drawing it is rather useless unless it’s somehow filterable/hideable ala real spreadsheets.
There’s a slight other possibility – part of the delay, IF the table is very large as far as pure volume of HTML text that is produced; and IF the network connection is not fast – could be due to having to download this.
If that’s the case, it’s VERY easy to test for: enclose your entire table in comment tag (
<!-- <TABLE> ... </TABLE> -->, assuming your table has no comment tags inside). Print some small text instead. after the comment tag closes.Then re-run the page.
If the small text shows in your browser very fast, it means that downloading the table was NOT the culprit (as well as another confirmation that CGI script is not the bottleneck); since you’d be generating and downloading the same large table file but not rendering the actual table on the browser.
If on the other hand it takes a long time to download the page with commented-out table to the end (and CGI was confirmed to be fast via log printing), you need to work on slimming down your page’s size – there are many techniques to do that but the are too big to fit on the margins of this answer.