我有这个Perl CGI程序，我允许用户选择要在此HTML表上查看的数据的数量。我浏览了foreach ... foreach ...并打印了每一行。
当Perl CGI脚本打印超过3,000行数据并且我的Firefox窗口无响应时，它会出现问题。我也链接dataTable jquery。
我可以采取哪些措施来防止冻结浏览器窗口？
答案 0 :(得分：3)
最有可能的是，浏览器窗口在显示大表时由于浏览器上的资源消耗而冻结;并且与你的后端Perl CGI代码无关。
确认这一点的最简单方法是将日志打印语句（例如打印到STDERR）附加到CGI脚本的最末端并打印时间戳;然后运行脚本并查看Web服务器日志以查看脚本何时完成。几乎可以肯定，你会发现它已经很快完成了。
另一个（虽然不太可靠）指标，它是作为瓶颈的浏览器，是在您操作系统中最喜欢的流程管理程序中观察消耗的内存和CPU（TaskManager / ProcessExplorer / ps / top）
现在，就浏览器显示的问题而言，Wrikken给出了一些很好的建议。如果可以的话，在一个非常大的桌子上避免复杂的事件处理（包括jQuery的东西）是一个好主意;尽可能使用类而不是ID。
其他人会：
为所有列使用预定义的像素宽度（理想情况下，所有列都用于讨价还价）。浏览器在渲染表时工作速度要快得多，因为它们不必为每一行动态计算它。
考虑切换到基于DIV的表而不是TABLE。说实话，我不知道这是否有助于加快速度 - 这是一个很好的问题或更好的问题，尝试它和基准。然而，它可能不是用于呈现列表数据的哲学上纯粹的解决方案。
正如Wrikken所说，分页。没有用户可以有效地处理3000行表，即使它快速地打印，所以实际绘制它是相当无用的，除非它以某种方式可过滤/隐藏真实的电子表格。
还有一点其他的可能性 - 延迟的一部分，如果表格非常大，只要生成纯HTML的HTML文本;如果网络连接速度不快 - 可能是因为必须下载它。
如果是这种情况，那么测试非常容易：将整个表格包含在注释标记（<!-- <TABLE> ... </TABLE> -->中，假设您的表中没有注释标记）。打印一些小文本。评论标签关闭后。
然后重新运行页面。
如果您的浏览器中的小文本显示速度非常快，则意味着下载表格不是罪魁祸首（以及CGI脚本不是瓶颈的另一个确认）;因为您将生成并下载相同的大型表文件，但不会在浏览器上呈现实际的表。
如果另一方面，下载带有注释表的页面需要很长时间（并且通过日志打印确认CGI很快），您需要减少页面大小 - 那里有很多技巧可以做到这一点但是这些技术太大而无法适应这个答案的边缘。
答案 1 :(得分：1)
可能的答案（按个人喜好排序）：
答案 2 :(得分：1)
显然，分页是最好的解决方案。 但是，有很多事情可以解决这类问题：
查看您的网络服务器是否已启用压缩。大多数现代浏览器（IE和FF）发送模式deflate标头，以便在Web服务器中启用压缩时，您将获得高度压缩的响应。就我而言，1Mb的响应降至87 Kb。
您可以安装尚未完成的firebug并跟踪有关您的脚本的所有详细信息，例如生成响应所花费的时间，响应下载花费的时间，rendring和客户端花费的时间脚本。同样可以在“网络标签”下找到。
我已经测试过，基于DIV的表不是这里的解决方案，只使用Divs用于布局和表格用于视图等。有时我们使用基于Div的表格布局，因为在IE中它可以在收到后立即显示而不是显示的表只接收关闭表标签。（与使用渐进式渲染的FF相比，这是默认行为）
一旦你跟踪时间，你的jquery可能会在客户端占用资源。
如果您只是想显示简单的表而没有太多花哨的东西，请使用perl printf将数据推送到客户端（浏览器），该客户端已经以表格的形式格式化并在PRE标签下显示。我正在显示一些4800行，9列，浏览器保持响应。
在这里，我正在以500个批量推送数据，以便响应开始尽快进行，看起来很顺利。