Question

我正在开发一个包含多个动态生成的表的页面，其中原始开发人员大致使用以下逻辑：

<table>
  <tr>...</tr>
  <asp:PlaceHolder ID="ph1" runat="server" />
</table>

在背后的代码中：

// Do lots of stuff
HtmlTableCell cell = new HtmlTableCell();
// set cell text, formatting, etc
ph1.Controls.Add(cell);
// repeat the above logic for every cell in the table

在一个页面中，这样的方法用于添加总共10-15行，其中10-15列分布在4-5个表中。表结构已设置，因此也可以通过在html中对表结构进行硬编码并在每个单元格中放置文字和标签来构建。页面本身存在一些性能问题。这是可能导致糟糕表现的因素之一。

问题是：

动态创建这么多表格单元格并在后面的代码中构建表格，而不是硬编码表格，并使用文字/标签来填充可能引入重大性能问题的数据（即：是否值得切换）？
或者更准确地说，在这样的情况下，它不会那么重要（或者至少不足以保证将动态表生成重写为硬编码表+文字所花费的时间）？

Answer 1

这不理想，但我怀疑真正的问题是提供该逻辑的数据源。加快用于获取数据的任何查询。

Answer 2

如果他们是，他们必须是如此边缘，你不会注意到。我用这种方式用10x50单元编码了一个gridviewish控件，与类似大小的静态表相比没有明显的性能问题。
在大多数情况下，您应该努力的是可维护性：）

Answer 3

简短回答：极不可能。

答案很长：这实际上取决于您对“显着”的定义。假设您在具有快速连接的体面服务器计算机上生成典型的HTML页面，则细分将如下所示：

从数据源加载数据：50-300ms
生成1125个表格单元格（15 x 15 x 5）：50-100毫秒
汇编HTML文档：10-20ms
通过互联网发送HTML页面：150-1000ms
在浏览器中呈现HTML页面：50-500ms

这些数字显然是估计数 - 重要的一点是步骤（2）与所有其他数据的关系。花费时间优化步骤（2）时，它占总成本的一小部分并不能很好地利用开发人员的时间。正如CodeSpeaker所说，清洁和可维护的代码是一个更好的投资。如果加载页面的总时间确实是一个问题，首先攻击主导成本（步骤1和4），然后再转到管道的其余部分。

Answer 4

此代码不通过使用文字（在任一方向上）显着增强性能，并且您提到的卷我怀疑您甚至可以衡量差异。

Answer 5

Yaakov，我更担心客户端会发生这样的渲染代码。我的意思是......这取决于您如何为每个单元格设置单元格渲染（格式化，CSS，类/ ID）。

如果您最终得到大型类名/ ID和内联CSS !!! ，那么您应该考虑手动生成表结构（甚至不使用文字）。在我看来，所有这些表内容都只是文本，因此您可以自然地呈现它而不需要任何控制开销。

可以在ASP.net中动态生成HTML表格导致重大性能问题吗？

5 个答案: