Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
А ведь точно, я под СВМ и сам делал. А вот под примусом вроде не получалось Ну тогда слава советским многомашинным комплексам! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2006, 12:04 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
c127 Сложные иерархические СУБД как раз сейчас обсуждаются в соседнем топике. Вместо того, чтобы болтать языком решили бы с помощью более сложного иерархического ХМЛ-я задачи с авиабилетами или со студентами-преподавателиями, глядишь кто-нибудь и заинтересовался бы зигзагом. А так вряд ли что-нибудь получится с продвижением устаревшей технологии на рынок, несмотря на титанические усилия продвигающих. Это вы XML обзываете устаревшей технологией? А что тогда говорить про таблицы, которые вы так усердно защищаете? Первоначальные реализации SQL работали с обыкновенными последовательными файлами (на тех же ЕС 1020). При этом использовались обыкновенные механизмы выборки, те самые SELECT. Я смотрю на XQuery, Zigzag и SQL только как на языковые инструменты. Сравнивать их реализации (и прежде всего быстродействие) здесь на форуме бессмысленно. Я уже когда-то пытался. Тоже можно сказать и про приложения, разработанные на основе этих языков. Поэтому я давно уже не демонстрирую и не продвигаю то, что мы разработали на основе Zigzag. Оно больше подходит для тех, кто работает с мобильными устройствами... Надеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными? Сомнения в быстродействии? Попробую вам объяснить это чисто логически. Надеюсь это не будет похоже на треп. Вы уже знаете как обычно представляется дерево в реляционной модели? Для: Код: plaintext 1. 2. 3. 4. 5. Узел Предок Свойство Представьте как будет решаться задача перехода от узла 1 к узлам 4, 5 и ниже. Вы не сможете обойтись без того, чтобы не сделать операцию выборки промежуточных вершин 2, 3. В современных реализациях XML в «поле зрения» будут находится сразу все вершины подчиненные 1 и это выполняется за одно обращение к внешнему устройству.... Если вас интересуют другие задачи, чисто табличные, по-моему я уже демонстрировал. Впрочем, могу продемонстрировать, если будет время, еще, как на XQuery, так и Zigzag. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2006, 14:09 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
авторПредставьте как будет решаться задача перехода от узла 1 к узлам 4, 5 и ниже. Вы не сможете обойтись без того, чтобы не сделать операцию выборки промежуточных вершин 2, 3. В современных реализациях XML в «поле зрения» будут находится сразу все вершины подчиненные 1 и это выполняется за одно обращение к внешнему устройству.... Это только при условии что таблица будет с примерной структурой: Узел Предок Свойство . А есть еще много вариантов. Да и моделировать объекты обычно приходится гораздо более сложной структуры чем дерево. Неважно устаревшая технология XML или нет, но использовать её как хранилище данных глупо. Для передачи информации, хранения каких-то настроек - да, замечательно. Но не нужно использовать там, для чего оно не предусмотрено ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2006, 14:40 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
авторНадеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными? само хранение данных в виде иерархии является неэффективным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2006, 14:44 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
1024 авторНадеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными? само хранение данных в виде иерархии является неэффективным. Прана-прана, таблицы в деревьями - изживать как класс! Запросы типа connect by prior - ф топку! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2006, 16:05 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
1024 авторНадеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными? само хранение данных в виде иерархии является неэффективным. Хотелось бы познакомиться с продолжением мысли. Или с предпосылками. Опустим XML. О иерархическом хранении данных, если можно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2006, 17:38 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
SergSuperЭто только при условии что таблица будет с примерной структурой: Узел Предок Свойство . А есть еще много вариантов. Треп. Пример эффективного представления неограниченного в глубь дерева на основе таблиц? SergSuperДа и моделировать объекты обычно приходится гораздо более сложной структуры чем дерево. Иерархическая модель может рассматриваться как множество таблиц, имеющих иерархическую зависимость. Каждый уровень иерархии по сути это таблица. Я не говорю об иерархии типов, как у Oracle, которое принципиально ничего не меняет. Я говорю об иерархии данных. Самый наглядный пример: Код: plaintext 1. 2. 3. SergSuperНеважно устаревшая технология XML или нет, но использовать её как хранилище данных глупо. Для передачи информации, хранения каких-то настроек - да, замечательно. Но не нужно использовать там, для чего оно не предусмотреноДля внутреннего представления даже в XML-СУБД совсем необязательно должен использоваться XML. Также как в РСУБД, внутреннее представление отнюдь не таблица. 1024само хранение данных в виде иерархии является неэффективным.Упссс. А как хранятся данные в архивах? Что такое по вашему B-tree индексация, применяемая в РСУБД? Сможете представить вашу файловую систему в виде таблиц? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2006, 17:58 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
ня> Хотелось бы познакомиться с продолжением мысли. Или с ня> предпосылками. Опустим XML. О иерархическом хранении данных, если ня> можно. Согласен, хранить существенные объемы в XML - глупо, ибо это текстовое представление по определению. Ни о какой эффективности и речи быть не может. ИМХО, идея XML как универсального средства сильно раздута производителями, которым требуется чем-нибудь привлечь клиента к новым версиям. Для задач с существенным уровнем иерархии данных, скорее, следует обратить внимание на объектные базы данных, например, такие как ObjectStore или AllegroCache. Эффективность их зиждется на том, что подавляющее большинство запросов осуществляют доступ к объекту (читай, записи) в по адресу (читай, идентификатору или первичному ключу), а не по набору условий WHERE. К тому же, в них присутствуют хорошая интеграция с каким-нибудь объектно-ориентированным языком программирования. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2006, 18:13 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
okdoky Треп. Пример эффективного представления неограниченного в глубь дерева на основе таблиц?Есть много вариантов Вот например простейший okdoky Иерархическая модель может рассматриваться как множество таблиц, имеющих иерархическую зависимость. Каждый уровень иерархии по сути это таблица. Я не говорю об иерархии типов, как у Oracle, которое принципиально ничего не меняет. Я говорю об иерархии данных ... А вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец. okdoky Что такое по вашему B-tree индексация, применяемая в РСУБД? Можно спорить как хранятся файлы, но уж индекс то данными никак не является. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2006, 18:19 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
SergSuper А вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец.Если база объектная, то два указателя на два родительских объекта, больших делов и по коллекции детишек в каждом родителе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2006, 20:15 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
SergSuper А вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец. . согласен - пример неудобный , но М-программист в этом случае может поступить почти так же, как PM: создать глобаль ^GT(дитя)=отец:мать и далее работать с ней ничуть не хуже чем R-программист с таблицей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2006, 22:19 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
okdoky Надеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными? Вообще-то не языки, ориентированные на обработку XML, а полуструктурированные (или слабоструктурированные) МД в контексте БД упоминаются, в связи с XML. А языки БД для иерахических данных, могут оказаться более удобными в общем случае совсем другие. Например, в иерархических и сетевых СУБД использовались навигационные языки БД. Возможно, в каких-то случаях они окажутся удобнее (в каком-то смысле и для кого-то), но, скорее всего, во многих случая реляционная или проч (ОО, ОР) (какая иерархия, а тем более произвольный граф) окажутся наиболее эффективными решениями в целом. Но иерахичиские, реляционные, ОО и ОР - сильноструктурированные МД. Вот если решающим где-то будет полуструктурированность, то там, может XML имеет шансы. И то сегодня еще это вряд ли в реальных ИС. Только, наверное, как что-то частное. okdoky Оно больше подходит для тех, кто работает с мобильными устройствами... В каком смысле? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 01:00 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
okdoky c127 Сложные иерархические СУБД как раз сейчас обсуждаются в соседнем топике. Вместо того, чтобы болтать языком решили бы с помощью более сложного иерархического ХМЛ-я задачи с авиабилетами или со студентами-преподавателиями, глядишь кто-нибудь и заинтересовался бы зигзагом. А так вряд ли что-нибудь получится с продвижением устаревшей технологии на рынок, несмотря на титанические усилия продвигающих. Это вы XML обзываете устаревшей технологией? А что тогда говорить про таблицы, которые вы так усердно защищаете? Лучше ничего не говорите о таблицах, в которых Вы мало смыслите. ХМЛ это иерархическая структура данных, которая появилась до реляционной модели, но очень быстро выяснилось, что практические задачи в виде деревьев не записываются. Всё, можно забыть об иерархической структуре, за исключением очень небольшого числа очень простых случаев. А ХМЛ это очередная попытка заработать деньги за счет тех, кто ничего не слышал об иерархических БД, об их проблемах и о том, что это уже проходили. okdokyНадеюсь, вы и сами догадываетесь, что языки, ориентированные на обработку XML, удобнее для работы с иерархическими данными? Никто не спорит, только иерархических данных в природе раз-два и обчелся. Как только данные слегка не иерархические, у иерархических БД вместе с ХМЛ-ем появляется куча проблем. Именно поэтому и придумали РСУБД. okdokyСомнения в быстродействии? Попробую вам объяснить это чисто логически. Надеюсь это не будет похоже на треп. Вы уже знаете как обычно представляется дерево в реляционной модели? Для: Код: plaintext 1. 2. 3. 4. 5. Узел Предок Свойство Представьте как будет решаться задача перехода от узла 1 к узлам 4, 5 и ниже. Вы не сможете обойтись без того, чтобы не сделать операцию выборки промежуточных вершин 2, 3. В современных реализациях XML в «поле зрения» будут находится сразу все вершины подчиненные 1 и это выполняется за одно обращение к внешнему устройству.... Оригинальное утверждение было: "Эта система работает быстрее чем любая РСУБД, особенно с данными имеющими иерархическую зависимость." /topic/354796&pg=3#3386388 Т.е. Zigzag всегда быстрее чем РСУБД, а когда с деревьями, так тем более. Вот и не съезжайте на деревья, расскажте о том, на основании каких данных Вы выяснили, что Zigzag "работает быстрее чем любая РСУБД" на любой задаче. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 02:58 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
43210 SergSuper А вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец.Если база объектная, то два указателя на два родительских объекта, больших делов и по коллекции детишек в каждом родителе. Ну вот пусть господин okdoky на XML и изобразит. А то на животных у него хорошо получается, пусть к людям перейдёт ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 10:01 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
SergSuper okdoky Треп. Пример эффективного представления неограниченного в глубь дерева на основе таблиц?Есть много вариантов Вот например простейший Опять треп. Где конкретный ответ (ссылка)? Это называется «запутывать следы». SergSuperА вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец. Переверните дерево и будет вам ответ. Если серьезно, любую сеть можно представить несколькими деревьями с пересекающимися (эквивалентными) вершинами. SergSuper okdoky Что такое по вашему B-tree индексация, применяемая в РСУБД? Можно спорить как хранятся файлы, но уж индекс то данными никак не является.…, но имеет прямое отношение к эффективному представлению или хранению. vadiminfo okdoky Оно больше подходит для тех, кто работает с мобильными устройствами... В каком смысле?Речь идет о приложениях реализованных на Zigzag. Один из примеров справочная ОРГАНИЗАЦИИ МОСКВЫ . c127Т.е. Zigzag всегда быстрее чем РСУБД, а когда с деревьями, так тем более. Вот и не съезжайте на деревья, расскажте о том, на основании каких данных Вы выяснили, что Zigzag "работает быстрее чем любая РСУБД" на любой задаче. Можно посмотреть предыдущий пример, справочную. Например, в «поиске организаций» можно сделать запрос по всем улицам на букву А. Их больше 100. Запрос в Zigzag выполнится мгновенно. При этом надо учесть, что используется невыделенный виртуальный хостинг (работает одновременно много других сайтов). Сама БД Zigzag используется не только для выполнения ваших запросов. Кроме того, интерфейс который вы видите генерируется автоматически на основе текущей БД. Увы, для этого тоже требуются запросы. Мы проверяли на SQL такие же запросы для индексированной таблицы с перечислением в WHERE более чем 100 значений. Они выполняются медленнее в 1,5 раза для MS Access. Кстати, MS Access работала в 2 раза быстрее чем Interbase и чуть быстрее MS SQL Server. Признаю, запросы проверялись только при однопользовательском режиме. Собственно контроль за множеством пользователей реализовать на Java несложно. Для этого используются и сервера приложений... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 13:15 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
...запрос по всем улицам на букву А. Их больше 100... ...перечислением в WHERE более чем 100 значений... Я дико извиняюсь, но ИМХО ... WHERE SOMEFIELD Like "A*"... это совсем не то что перечисление в WHERE более чем 100 значений / Ежели Вы так сравниваете, и на полном серьезе нам предлагаете рассматривать это как критерий истины, то... ГЫ-ГЫ-ГЫ-US ...простите не удержался..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 13:25 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
okdoky Речь идет о приложениях реализованных на Zigzag. Это то я понял. Не понял почему они лучше для тех кто работает с мобильными устройствами. Чем лучше? Быстрее работает, Быстрее на ней реальную ИС разработать, Легче сопровождать? Или для мобильных устройств другие в принципе не подходят? Я это имел в виду уточнить. В чем там особенность мобильности проявляется, которая делает других хуже? Для тех кто работает немобольными устройствами, как я понял, они не лучше уже? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 13:28 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
авторХотелось бы познакомиться с продолжением мысли. Или с предпосылками. Опустим XML. О иерархическом хранении данных, если можно. файловая система - найти файл в папке легко. Просто открыть эту папку. Найти файл по размеру трудно. Нужно переоткрывать все папки и просматривать файлы. гениологическое дерево - найти всех детей родителя легко. Просто перейти в узел родителя и подсчитать. Определить сколько в роду было Ме и сколько Жо - трудно. Нужно пройти по всем узлам. Хранение данных в виде иерархии позволяет легко выполнять поиск по критериям совпадающим с этой иерархией и крайне затрудняют по остальным параметрам. В этом смысл отказа от деревянных структур. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 13:38 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
okdokyМожно посмотреть предыдущий пример, справочную. Например, в «поиске организаций» можно сделать запрос по всем улицам на букву А. Их больше 100. Запрос в Zigzag выполнится мгновенно. При этом надо учесть, что используется невыделенный виртуальный хостинг (работает одновременно много других сайтов). Сама БД Zigzag используется не только для выполнения ваших запросов. Кроме того, интерфейс который вы видите генерируется автоматически на основе текущей БД. Увы, для этого тоже требуются запросы. Мы проверяли на SQL такие же запросы для индексированной таблицы с перечислением в WHERE более чем 100 значений. Они выполняются медленнее в 1,5 раза для MS Access. Кстати, MS Access работала в 2 раза быстрее чем Interbase и чуть быстрее MS SQL Server. Признаю, запросы проверялись только при однопользовательском режиме. Собственно контроль за множеством пользователей реализовать на Java несложно. Для этого используются и сервера приложений... Ну, я бы не сказал, что оно так уж мгновенно работает. По одной букве в названии улицы оно искать вообще отказывается, по "мо" реакция была порядка двух секунд, например. Ничем не выдающийся результат, для выборки полутора тысяч объектов из 125 000. Вполне могли б и какой-нить MySQL использовать, который для хостинга куда менее экзотичен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 13:48 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
Мимо пробегал......запрос по всем улицам на букву А. Их больше 100... ...перечислением в WHERE более чем 100 значений... Я дико извиняюсь, но ИМХО ... WHERE SOMEFIELD Like "A*"... это совсем не то что перечисление в WHERE более чем 100 значений / Ежели Вы так сравниваете, и на полном серьезе нам предлагаете рассматривать это как критерий истины, то... ГЫ-ГЫ-ГЫ-US ...простите не удержался.....Да с запросом ... WHERE SOMEFIELD Like "A*"... SQL работает чуть быстрее, чем с перечислением. Речь идет именно о перечислении WHERE улица='А...' OR улица='А...' ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 14:08 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
С трудом представляю, для чего в этой задаче и на нормализованной БД может потребоваться перечисление из сотни альтернатив. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 14:16 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
Афигеть :) Вы хоть сами то прикинте, скока это "чуть быстрее" на самом деле означает. "Like A*" это фактически поиск толко по первой букве, А WHERE улица='А...' OR улица='А...' ... это точное сранение знавчения поля с искомым значением - и это для более чем для ста значений. Так что Ваше "чуть быстрее" - это ИМХО "быстрее в порядки". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 14:19 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
То есть если средняя длина названия улицы = 10 символам, то точное сравнение означает 10 посимвольных сравненй. Для более чем ста значений мы получаем более 1000 сравненй. А Like "A*" ' это всего одно сравнение (первого символа). Это "чуть быстрее"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 14:23 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
okdoky SergSuper okdoky Треп. Пример эффективного представления неограниченного в глубь дерева на основе таблиц?Есть много вариантов Вот например простейший Опять треп. Где конкретный ответ (ссылка)? Это называется «запутывать следы». okdoky, ну если Вы не знаете элементарных вещей, почему надо так неуважительно называть мои высказываниям? Дерево можно хранить с помощью множественной модели, когда каждая ветвь рассматривается как множество и можно проверять входит ли одно множество в другое или нет. Реализации могут быть различны. Пример можно посмотреть тут . А в ссылочке там ошибка была, правильно /topic/351164&pg=29#3393086 okdoky SergSuperА вот изобразите-ка гениалогическое дерево. Но только что б там были оба предка(мать и отец), а не только по отец. Переверните дерево и будет вам ответ. Если серьезно, любую сеть можно представить несколькими деревьями с пересекающимися (эквивалентными) вершинами. Т.е. в XML-е это не изобразить(надеюсь Вы сами понимаете, что перевернуть недостаточно)? Пойдём дальше - любое дерево можно представить в виде таблицы с пересекающимися ячеками okdoky SergSuper okdoky Что такое по вашему B-tree индексация, применяемая в РСУБД? Можно спорить как хранятся файлы, но уж индекс то данными никак не является.…, но имеет прямое отношение к эффективному представлению или хранению. Косвенное, косвенное. Только для ускорения получения. Ну собственно то высказывание было не моё, а спор тут чисто теоритический okdoky Речь идет о приложениях реализованных на Zigzag. Один из примеров справочная ОРГАНИЗАЦИИ МОСКВЫ . Это... постеснялись бы такое показывать, что ли... я конечно понимаю что это единственное в мире что было сделано на зигзаге, но всё равно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 14:39 |
|
||
|
Почему только русские СУБД
|
|||
|---|---|---|---|
|
#18+
Мимо пробегал...То есть если средняя длина названия улицы = 10 символам, то точное сравнение означает 10 посимвольных сравненй. Для более чем ста значений мы получаем более 1000 сравненй. А Like "A*" ' это всего одно сравнение (первого символа). Это "чуть быстрее"?Вот поэтому я и предлагал зайти в справочную и посмотреть как будет работать Zigzag с таким большим перечислением. Тем более что запрос сделать просто, система сама предлагает список возможных улиц или других атрибутов имеющихся в текущей БД . Ну а запрос на A* в Zigzag конечно тоже можно сделать: Код: plaintext Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2006, 15:22 |
|
||
|
|

start [/forum/topic.php?fid=35&startmsg=34123377&tid=1553439]: |
0ms |
get settings: |
7ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
40ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
71ms |
get tp. blocked users: |
2ms |
| others: | 177ms |
| total: | 334ms |

| 0 / 0 |
