Интересно бы почитать сравнение с jsUnit

Ну, если вы посмотрели и выяснили, что bottleneck в строго определенном месте и это место - доступ к данным, тогда оптимизацией этого места и стоит заняться.

Улыбнуло :-) Особенно на фоне тех шестилитровых пикапов, на которых эти "экономные" амеры любят ездить.

Да, Виталик, ты прав - проблема в извлечении данных. Но тут врядли что-то получиться исправить, скорее придумать иной способ извлечения данных. Мы сейчас думаем над использованием базы данных, возможно встроенной или попробовать заюзать xslt для формирования html файлов. Саша, страница слава богу не популярная и пользуются ей 2-3 человека. А dotTrace смотрели, но ничего нового не увидели - страница слишком проста, чтобы там затерятся 3333-ем поползновениям к источнику данных.

Да, Паш, именно это и смутило :) Если у вас на одном пользователе такая загрузка, то что будет, если эту страницу откроют 2, 5, 10 пользователей? Возможно, это не самая популярная страница, но что-то мне подсказывает, что такая ситуация потенциально возможна. Это же веб. Если вы еще не пробовали запускать dotTrace, то я вам настоятельно рекомендую это сделать. Я у нас на проекте уже раз пять оптимизировал отдельные страницы приложения и один раз - все приложение в целом. Садился, записывал, разбирался. Как правило, оказывало, что у нас то алгоритм неоптимальный, то локального кеширования где-то нет и вместо этого мы 3333 раза лезем в базу вместо одного, то идет дублирование вызовов. И все это лечится за 5-10 минут, а прирост производительности в определенных ситуациях может достичь двух порядков.

Думаю, как раз это смутило не только нас, но судя по ночному звонку, заказчика тоже... Если удалось успокоить его 10% ослаблением нагрузки - вероятно это не надолго и стоит воспользоваться передышкой и ускорить процедуру извлечения (обработки) данных, если проблема всё же в ней...