frid-karatel,
попробуй разбить таблицу из 1000 строк на 10 таблиц из 100 строк.

Дело именно в отрисовке?
Попробуйте найти узкое место - запустите цикл "вхолостую", с записью не в innerHTML, а в какую-нибудь левую переменную;
в реальную таблицу, у которой display:none;
в реальную таблицу, у которой table-layout: fixed.

Просто возможно, что тормозит не математика и DOM, а reflow.

Код:

TABLE.prototype.Print = function() {
  this.Sort();
  /*
  Сортировка по принципу вызова доп. функции к эл-ту
  т.е.
  if (a > b)
    return 1;
  else
    return -1;
  return 0;
  */
  for (ri = 0; ri < rc; ri++) {
    for (ci = 0; ci < cc; ci++) {
      switch(...) {
        /* как бы array.push(...) */
      }
    }
  }
  document.body.innerHTML = array.join('');
}

Вот результаты:
- Весь код ~ 296 мс
- Без вывода в innerHTML ~ 66 мс
- Без вывода в innerHTML + без сортировки ~ 12 мс

Дело в рендеринге. Быстрее, чем Fx сможет нарисовать эту таблицу, показаться она не сможет.

Кстати, я тут бенчмарк небольшой устроил — вывод таблицы 10×1000 занял…
Opera 10: 10 секунд
Opera 10.50a: 17 секунд (они делают ее медленнее?!)
Firefox 3.5: 24 секунды
Chrome: 4 секунды
IE8: 14 секунд

а теперь сделай её фиксированой..

В каком плане?

Кстати, был у меня интересный вариант в плане "усовершенствования"...
В частности, на C++ такой вариант работал - это создание сразу 1000 строк, а потом скрывать те, которые не нужны...

То есть создать один раз таблицу, а затем ее заполнять... Если строк всего 100 штук, то остальные 900 штук сделать display:none..

Как такой вариант?

А теперь 10 таблиц 10х100.

table-layout:fixed

В стилях это прописано ;)

Блин, почему же у лиса такой "не шустрый" JS движок... мне кажется, это должно быть одним из основных направлений разработки браузеров, т.к. все активней используется генерация страницы на компьютере пользователя...

Вот запустил этот код на Chrome - 88 мс (!) против ~300 Firefox'а... капец... :blink: