MtW> Я столкнулся с тем эффектом, что пересчёт изменения размеров колонок MtW> таблицы по мере добавления в неё нового текста (по мере чтения MtW> заголовков сообщений) начинает занимать довольно существенное время MtW> (едва ли не большее, чем время чтения самих заголовков), если число MtW> сообщений в эхе превосходит примерно 1000. Вы увидите, что на скриншоте MtW> показаны заголовки только первых четырёх сообщений из эхи MtW> Ru.Fidonet.Today; но мне не пришлось обладать реакцией истинных ниндзя MtW> для того, чтобы успеть нажать Alt+PrtScr раньше, чем отобразится пятое. MtW> Тут всё дело в тормозах: у меня хранится база Ru.Fidonet.Today MtW> за последние 7 лет (с февраля 2007 года по февраль 2014 года), и в ней MtW> чуть менее 26000 сообщений.
MtW> Естественно, с этим эффектом я намерен побороться и одолеть его ── ну, MtW> скажем, после каждых 500 сообщений стану оканчивать старую таблицу и MtW> начинать новую.
И поборолся, и одолел.
Метод, которым я добился ускорения процесса, был, видимо, тем же самым, какой и в GoldED используется: отображать заголовки не всех сообщений эхопочты (это долго, когда их десятки тысяч), а только видимых в настоящее время на экране.
И так как следить за видимостью десятков тысяч сообщений также весьма накладно, то я именно то и сделал, что поделил их на отдельные таблицы (даже не по 500 сообщений, как первоначально собирался, а по 250 сообщений в каждой таблице), после чего стал следить за видимостью на экране не отдельных сообщений, а лишь таблиц.
Кроме того, отображение заголовков сообщений из первой таблицы можно начать даже прежде, чем последующие таблицы вообще появляются на странице; это также положительно действует на наблюдаемую читателем скорость работы, потому что он видеть и читать заголовки может с самого начала ── а откручивать страницу к последующим сообщениям он станет в любом случае позже.
Изложенный по адресу http://dbaron.org/log/20100309-faster-timeouts трюк позволил мне выиграть примерно четыре миллисекунды (а если по стандарту http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers судить, то и ровно четыре миллисекунды) при исполнении каждого из отложенных действий. Казалось бы, четыре миллисекунды ── это пустяк; но если в таблице 250 сообщений, то выигрыш четырёх миллисекунд на каждом из них означает, что таблица отображается на целую секунду быстрее. Это по-настоящему заметно.
К сожалению, заметно и то, что хранение в памяти заголовков десятков тысяч сообщений эхопочты и работа отображающего их движка приводит ко пропорционально немалому потреблению памяти. PhiDo может в таких случаях отожрать примерно мегабайтов шестьсот оперативной памяти.
Таким образом, я столкнулся с тем, что рекомендуемым объёмом оперативной памяти станет для моего фидобраузера (PhiDo) объём двухгигабайтный: если в системе памяти один только гигабайт, то PhiDo не уместится в нём вместе с операционною системою и другими приложениями (среди которых наверняка есть и веб-браузер; никто же не станет закрывать веб-браузер для того, чтобы открыть фидобраузер в высвободившейся памяти и облазать им Фидонет), неизбежным будет торможение системы, неизбежным будет начало интенсивной работы с файлом подкачки. Я лично убедился в этом, некоторое время погоняв PhiDo на системе с единственным гигом оперативной памяти, да ещё параллельно с открытыми в Файерфоксе несколькими страницами Всемирной Паутины.
Как вы считаете, насколько это стеснит фидошников? Много ли в наши дни таких читателей Фидонета, у которых в системе один гигабайт оперативной памяти?
* изначально написано в эхоконференцию Ru.Fidonet.Today * также было отослано в эхоконференцию Ru.FTN.Develop
Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/ Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]
... В войне не бывает второго приза для проигравших. (Омар Брэдли) --- Последнее из недочитанного: Василий Аксёнов, "Остpов Кpым" - возненавидел. * Origin: Всё зло, причинённое народу, должно быть смыто КРОВИЩЕЙ (2:5063/88)
