如何在 Perl CGI 程序中输出大型 HTML 表而不冻结浏览器？
我有这个 Perl CGI 程序，我允许用户选择要在此 HTML 表上查看的数据数量。我通过 foreach ... foreach ... 并打印每一行。
当 Perl CGI 脚本打印超过 3,000 行数据并且我的 Firefox 窗口变得无响应时，它会出现问题。我还链接了 dataTable jquery。
我可以采取哪些方法来防止浏览器窗口冻结？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
最有可能的是，浏览器窗口由于显示大表格时消耗浏览器资源而冻结；与你的后端 Perl CGI 代码无关。
确认这一点的最简单方法是将日志打印语句（例如打印到 STDERR）附加到 CGI 脚本的最后并打印时间戳；然后运行脚本并查看 Web 服务器日志以查看脚本何时完成。几乎可以肯定，您会发现它完成得非常快。
另一个（尽管不太可靠）指示浏览器是瓶颈的指标是观察操作系统上您最喜欢的进程管理程序（TaskManager/ProcessExplorer/ps/top）中消耗的内存和 CPU
现在，就浏览器显示的问题而言，Wrikken给出了一些很好的建议。如果可以的话，避免在非常大的表上进行复杂的事件处理（包括 jQuery 的东西）是一个好主意；尽可能使用类而不是 ID。
其他一些是：
对所有列（最好是所有行）使用预定义的像素宽度。浏览器在渲染表格时工作速度要快得多，因为浏览器不必为每一行动态计算此值。
考虑切换到基于 DIV 的表而不是 TABLE。老实说，我不知道这是否有助于提高速度——这将是一个很好的问题，或者更好，尝试一下并进行基准测试。不过，它可能不是用于呈现表格数据的哲学上纯粹的解决方案。
正如 Wrikken 所说，分页。没有用户可以有效地处理 3000 行的表，即使它打印得快得令人眼花缭乱，所以实际上绘制它是相当无用的，除非它以某种方式可过滤/可隐藏，就像真正的电子表格一样。
还有一种轻微的其他可能性 - 部分延迟，如果表对于生成的纯 HTML 文本量而言非常大；如果网络连接速度不快 - 可能是由于必须下载此内容。
如果是这种情况，测试起来非常容易：将整个表格放在注释标记中（
，假设你的表里面没有评论标签）。而是打印一些小文本。评论标签关闭后。然后重新运行该页面。
如果小文本在浏览器中显示得非常快，则意味着下载表格不是罪魁祸首（同时也确认 CGI 脚本不是瓶颈）；因为您将生成并下载相同的大表文件，但不会在浏览器上呈现实际的表。
另一方面，如果下载带有注释表的页面需要很长时间（并且通过日志打印确认 CGI 速度很快），那么您需要努力缩小页面的大小 - 有很多技术这样做，但它们太大了，无法容纳在这个答案的边缘。
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.
可能的答案是（按照个人喜好的顺序）：
Possible answers are (in order of personal preference):
显然分页是这里最好的解决方案。
但是可以采取多种措施来处理此类问题：
查看您的 Web 服务器是否启用了压缩。大多数现代浏览器（IE 和 FF）都会发送模式 deflate 标头，这样如果在 Web 服务器中启用了压缩，您将获得高度压缩的响应。对于我的情况，1Mb 的响应降至 87 Kb。
您可以安装尚未完成的 Firebug 并跟踪有关脚本的所有详细信息，例如生成响应花费了多少时间、下载响应花费了多少时间、渲染和客户端脚本花费了多少时间。 “网络选项卡”下也提供了相同的功能。
我已经测试过，基于 DIV 的表格不是这里的解决方案，仅使用 Div 进行布局，使用表格进行视图等。有时我们使用基于 Div 的表格布局，如在 IE 中，它可以在收到后立即显示，而不是表格仅显示关闭表格标记。（与使用渐进式渲染的 FF 相比，这是默认行为）
一旦您跟踪计时，您的 jquery 可能会出现问题，耗尽客户端的资源。
如果您只想显示简单的表格，没有太多花哨的东西，请使用 perl printf 将数据推送到客户端（浏览器），该数据已经以表格形式格式化并在 PRE 标签下显示。我正在显示一些 4800 行 9 列的内容，并且浏览器保持响应。
在这里，我以 500 行为一组推送数据，以便响应尽快开始发送，并且看起来很顺利。
Obviously Pagination is the best solution here.
But there are a number of things that can be done to deal with this kind of issues:
See if your web server has compression enabled. Most modern browsers(IE and FF) send mode deflate headers so that if compression is enabled in web server, you get highly compressed response. For my case a response of 1Mb was down to 87 Kb.
You can install firebug of not done already and track all details about your script like how much time was taken to generate the response, how much time is taken in response download, how much time is taken in rendring and client scripts. Same is available under "Net tab".
I have tested and DIV based tables are not the solution here, Use Divs only for layout and tables for views etc. Some times we use Div based table layout as in IE it can be displayed as soon as its received instead of tables which are displayed only closing table tag is received.(This is the default behaviour as compared to FF where in progressive rendering is used)
Once you track timings, it could be issue with your jquery to eat up resources on client side.
If you just want to display simple table without much fancy stuff use perl printf to push data to client(browser) which is already formatted in form of table and display it under PRE tag. I am displaying some where 4800 rows with 9 columns and browser remain responsive.
Here I am pushing data in batches of 500rows so that response starts comming asap and it seems smooth.