Firefox дает сбой при рендеринге большой HTML-таблицы (более 20 000 строк) - PullRequest
Новая
       16

Firefox дает сбой при рендеринге большой HTML-таблицы (более 20 000 строк)

8 голосов
/ 15 июня 2009

Я понимаю, что рендеринг таблицы такого размера раздвигает границы любого браузера. Тем не менее, мне было любопытно, почему достаточно большая таблица (более 20 000 строк) приводит к сбою Firefox, тогда как все остальные браузеры отображают его относительно быстро.

Я использую ASP.NET и записываю таблицу html напрямую в буфер с помощью Response.Write. Сначала я подумал, что, может быть, я генерирую какой-то искаженный HTML, поэтому я решил воссоздать таблицу с видом сетки. Это еще больше замедлило Firefox, но в других основных браузерах время рендеринга было немного медленнее.

Firefox создает первые (приблизительно) 10000 строк просто отлично. Проблема заключается в том, что после этого он очень медленно добавляет оставшиеся строки, пока приложение не перестает отвечать на запросы, в то же время используя увеличивающийся объем памяти (более 300 МБ). Internet Explorer использует только около 30 МБ.

Я использую самую последнюю версию Firefox, и все мои надстройки отключены во время тестирования. Также я удалил все css и javascript со страницы.

Это известная проблема с firefox? Кто-нибудь еще испытывал это? Какие шаги можно предпринять, чтобы устранить проблему или хотя бы начать устранение неполадок?

EDIT Я знаю, что иметь столько строк таблицы на странице - это ужасная практика проектирования пользовательского интерфейса. Спасибо всем, кто указал на это, но это был не мой вопрос. Для дальнейшего разъяснения мне было просто любопытно, почему это работает во всех браузерах, кроме Firefox.

Ответы [ 9 ]

7 голосов
/ 15 июня 2009

попробуйте определить таблицу с фиксированной шириной 

<table style='table-layout:fixed'>

Это позволит браузеру отображать таблицу, не пытаясь пересчитать ширину при каждом добавлении новой строки.

[UPDATE]

Я не уверен, как выглядят ваши данные, но я могу сделать 

<table style='table-layout:fixed'>
<tr><td style="width:150px;"></td><td style="width:150px;"></td><td style="width:150px;"></td><td style="width:150px;"></td><td style="width:150px;"></td></tr>
<%
    for (int ix = 0; ix < 30000; ix++)
    {
        Response.Write("<tr>");
        Response.Write("<td><img src='stickman1.bmp'></td>");
        Response.Write("<td>" + RandomString() + "</td>");
        Response.Write("<td><img src='stickman2.bmp'></td>");
        Response.Write("<td>" + RandomString() + "</td>");
        Response.Write("<td><img src='stickman3.bmp'></td>");
        Response.Write("<td><a href='#' onclick='blah();'>stick man!</a></td>");
        Response.Write("</tr>");
    }

 %>
 </table>

в Firefox 3.0.11. Хотя это займет некоторое время, Firefox покажет его. Это потребляло 239 МБ оперативной памяти. RandomString () просто возвращает строку длиной от 0 до 22 символов.

4 голосов
/ 15 июня 2009

Возможно, вы захотите использовать нумерацию страниц , чтобы разобраться с этим :) Я думаю, что мой бедный старый ноутбук умрет, если Firefox попытается отобразить 20 тыс. Строк таблиц. И это Core2 с 4 ГБ оперативной памяти: P

3 голосов
/ 15 июня 2009

Возможно, это как-то связано с вашими данными? Я только что открыл простую страницу ASP.NET, которая создает таблицу строк размером 50 КБ, а Firefox прекрасно ее отображает. 

protected void Page_Load(object sender, EventArgs e)
{
    StringBuilder sb = new StringBuilder();
    sb.Append("<table><tbody>");
    for (int i = 0; i < 50000; i++)
    {
        sb.Append("<tr><td>My Name</td><td>my@email.com</td></tr>");
    }
    sb.Append("</tbody></table>");
    Response.Write(sb.ToString());
}
3 голосов
/ 15 июня 2009

РЕДАКТИРОВАТЬ: Исходя из того, что вы показали в своих комментариях, я бы предположил, что проблема, скорее всего, связана с вашими данными, чем с таблицей. Вам нужно будет выполнить несколько тестов, используя различные данные, элементы и методы компоновки, чтобы определить причину проблемы. Я бы особенно искал:

  • объект, iframe или собственные элементы (включая элементы формы).
  • дубликаты атрибутов идентификатора
  • неоткрытые сущности
  • тегов в потоке данных, особенно </td>, </tr> and </table>
  • colspans

хммм .. похоже на то, что вы не используете правильный html (не закрываете строки или что-то в этом роде). Запустите подмножество вашей таблицы через валидатор.

table-layout: исправлено (согласно ответу Джека), рендеринг должен выполняться до тех пор, пока не произойдет сбой. Кажется, что он ничего не знает о таблице заранее (например, о ее ширине). Попробуйте установить ширину в пиксельное значение и использовать элементы col. 

<table style='table-layout:fixed; width:800px'>
  <col style="width:200px">
  <col style="width:600px">
  <tr>
     ...
1 голос
/ 15 июня 2009

Другая мысль

Сколько времени занимает отправка информации? Это буферизовано на стороне сервера? Может быть связано с обработкой соединения в Firefox, а не с обработкой .

1 голос
/ 15 июня 2009

Я бы предложил использовать разбиение на страницы для набора данных такого размера. ExtJS имеет очень хороший GridPanel, который прост в реализации (вы можете посмотреть исходный код примеров для руководства), и если вы хотите что-то не настолько «экстремальное» (как, например, это не так) не нужно менять внешний вид таблицы), jQuery также имеет некоторые элементы AJAX Pagination.

0 голосов
/ 27 апреля 2014

Кроме того, Firefox не очень предпочтительный браузер - стандарт html5, который отлично работает в Chrome и Opera, на самом деле не работает в Firefox

0 голосов
/ 14 июля 2009

У меня та же проблема. В основном Firefox очень медленно прокручивается при отображении таблицы (30 строк и около 50 столбцов). Как только таблица больше не видна, браузер снова быстро прокручивается. Поэтому я думаю, что это проблема отображения или обновления дисплея.

0 голосов
/ 21 июня 2009

Я думаю, что большая часть проблемы заключается в том, что Firefox (по крайней мере, в предыдущих версиях, это могло быть исправлено к моменту прочтения этого сообщения), как правило, использует много памяти само по себе, даже когда ничего особенного не происходит.

Загрузка огромного количества данных означала бы, что для него требуется еще больше памяти и ресурсов ЦП, чем обычно, а для системы обычно требуется довольно много. Поэтому, если бы объем данных был огромен, он мог бы использовать все ресурсы, и Firefox достаточно вежлив, чтобы сдаться, а не сбить компьютер.

Я полагаю, что производительность будет отличаться, если вы попробуете это на очень низкоуровневой системе по сравнению с высокопроизводительной системой с большим объемом памяти и быстрым ЦП.

Конечно, это также зависит от того, что вы подразумеваете под падением. Точный смысл сбоя в том, что он перестает работать и выходит, тогда как вы можете говорить о том, что он просто зависает (он перестает работать, но не выходит), и в этом случае возможно, что он все еще работает, но пытается отрисовать страницу перед вами. потерять терпение.

Если вы вручную закроете Firefox перед отображением страницы, это технически не будет считаться сбоем, просто зависанием или тем, что пользователь недостаточно терпелив, чтобы дождаться загрузки страницы (конечно, существует ограничение чье-либо терпение!).

...