|
|
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Не, все хуже. String'и и все остальное работает крайне быстро. Тут все упирается в JIT-компилятор. А вот как он код оптимизирует - ведает только он. Тот конечный автомат, который написал я, банально стоит колом на IF...'а и SWITCH'е (для определения что пришло во входном потоке \t,\n,\r или просто символ). От перестановки IF..ELSE местами, скорость меняется в разы. Только не понятно, толи я уже наткнулся на предел работы процессора (промахи предсказания перехода, промахи кеша), толи приколы JIT компилятора. Толи все вместе. Но как стандартный код умудряется давать ту же скорость - мне не понятно, но честно говоря, практического интереса для меня не представляет. Хотя, возможно, я где-то с замерами ошибся . У меня файл 844 Mb (лям строк, 50 полей) предельные цифры: чтения с диска 700 ms (844/0.7=1205 Mb/s, явно из кэша ОС читает), 1251 -> char = 100 ms, и парсинг + конструирования string[] от 1.1 до 3 сек. Если переписать 10 строк Java на Native код, будет быстрее. Но сейчас 30% времени - тупо чтение файла (нативные методы JRE), 60% обработка. Т.е. Java -> Native C даст выигрыш на _всей_ задачи парсинга не более в 3 раза. С учетом последующей обработки (зачем-то же файл читается) - еще меньше. Оно того нужно? По совокупности, а не ради спортивного интереса. Ради спортивного интереса можно и на асме под проц. затачивать (смотреть в Intel Vtune и промахи оптимизировать) или много-потоковую обработку файла (как в Oracle ))) parallel full table scan и etc ))) ) сделать. Да на кластер! Вот где скорость будет! Если автор оплатит - можно и запилить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 12:44 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevЕсли переписать 10 строк Java на Native код, будет быстрее. Но сейчас 30% времени - тупо чтение файла (нативные методы JRE), 60% обработка. Т.е. Java -> Native C даст выигрыш на _всей_ задачи парсинга не более в 3 раза. Думаю что не будет быстрее. У вас будут накладные расходы на JNDI callbacks в случае если вы должны всё равно переходить в контекст Java-кода. Если мы говорим о С++ - то это оффтопик и отдельный вопрос в отдельный форум. В целом I/O (since 6) Java IO (NIO) достаточно хорошо написан чтобы вообще не думать о явном использовании средств ОС. Если у автора стоит задача - прогрузить это всё в БД (bulk load/bulk insert) то надо сначала выкурить всякие утилитки от вендора БД, собрать на их базе макет или скриптик, потестировать а уж после этого делать свой bulk-велосипед. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 12:53 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
JNI тоесть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 12:53 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
В общем, запустить ИСХОДНЫЙ C++ и Java код на своем компьютере со своим примером файла 885 Mb. C++ (откомпилировано в Debug mode /без оптимизации/, вызов gettimeofday заменен на timeGetTime): потребление памяти по Task Manager из Windows 921 584 Mb parsing + create collection = 9100 free memory = 977 C++ (откомпилировано в Release): parsing + create collection = 3457 free memory = 160 Java, старый алгоритм автора, но сохраняет все данные в ArrayList<String[]> (Ну не люблю я списки и деревья! Старая, десятилетняя ненависть!). Настройки JVM -Xms8000m -Xmx8000m ParserOld time=2823 Total Garbage Collections: 1 Total Garbage Collection Time (ms): 480 arr.size=1000000 totalMemory=8039104512 freeMemory=6197443160 usedMemory=1841661352 ----- Total Garbage Collections: 5 Total Garbage Collection Time (ms): 1369 totalMemory=8039104512 freeMemory=8038830432 usedMemory=274080 total time=3715 Отсюда вопрос: и где Java медленнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 13:34 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Леонид! На что мы должны смотреть? Здесь ничего нет. Нет кода который можно было-бы комментировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 13:41 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Сравнение i/o на java и на c/c++ в основном это замеры оверхеда от выделения памяти виртуальной машиной т.к. все массивы байт скопируются по N-раз пока дойдут до места, где java-разработчик может ими начать оперировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 13:44 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
maytonДумаю что не будет быстрее.... Будет, будет... ))) JNDI вряд ли сильно большие накладные расходы дает, оно же в одном окружении. Зато на C и ASM'е можно с предсказателем переходов поиграться ))) и правильный порядок If...else... поставить ))) В общем, пока моя имплементация конечного автомата медленнее исходной реализации автора на стандартных Java функция (((. Правда зато память используется намного меньше! А память это лишняя работа GC, при многопотоковости/многопользователях это может быть важнее, чем пиковая скорость. Вообще, тема интересная. Много нового о Java узнал. Только расстраивает, что JIT-компилятор совершенно черный ящик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 13:45 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, при чём здесь вообще Си и Ассемблер? При чём здесь вообще if-else ? Это всё вопросы не в тему топика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 13:52 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
А чего коментировать? Исходная задача автором не описана. Исходного файла от автора нет. То, что Java ЗНАЧИТЕЛЬНО медленнее C++, он НЕ прав. Исходной код автора 15580799 C++[/msg] и 15576134 Java[/msg], работает лично на моей машине одинаковое/сравнимое время. Если -Xms8000m -Xmx8000m выставить ))). При этом, замеры скорость явно выше скорости чтения с физических дисков /даже мой SSD такой скорости давать не должен/. Т.ч. мерится сферический конь в вакууме. На реальной задаче , Subj смысла не имеет. Мне профит: прочитал кучу статей о JIT-компиляторе и узнал кое-что новое по синтаксису Java. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 14:02 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
maytonLeonid Kudryavtsev, при чём здесь вообще Си и Ассемблер? При чём здесь вообще if-else ? Это всё вопросы не в тему топика. Притом, что скорость исходного кода автора, при нормальной настройке окружения Java - похоже приближается к пределу железа. Выделение памяти/объектов, для Java операция почти "бесплатная" (если в eden) Если хочется быстрее "парсить" (проверять пришедший символ на \r, \n) - то тогда только оптимизация под проц (промахи переходов, кеша и т.д.) ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 14:18 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Я напоминаю что мы находимся в форуме Java и автору, скорее всего будут неинтересны решения на pure C/C++/Assembler. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 15:14 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1ОзверинЯ может чего то не понимаю, как bufferedreader может быть быстрее filechannel? Вы не ошиблись? filechannel быстрее bufferedreader . (кажется по ссылке что я указал это как раз и описано ) но именно ваш код используется Files.readAll или что то типа того, которая является оберктой для bufferedreader`а.?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 22:00 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1исходный файл на 1 млн строк вида ( размер порядка 65 Мб) : авторname date phone email cost Имя1 16.04.2014 07:16:15 79294595328 vrghjm0@gmail.com 110 Имя2 19.05.2014 06:48:26 79933782391 p25ghjgt1@ya.ru 23 имя2 08.06.2014 05:40:37 79812440379 h7ghgfh48@list.ru 15 JAVA лучшее время read file 899 ms Код: java 1. 2. 3. 4. 5. 6. 7. total heap usage:1,000,023 allocs, 1,000,023 frees, 86,061,056 bytes allocated Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. (Тут есть один нюанс - если читать в с++ файл построчно - не в массив ,то время будет в два раза лучше , чуть больше 65 ms) Хм.. У меня не такой большой отрыв. Java GCC 4.6.2 MS VS 2010 (дабл кликом по exe'шнику) Из-под визуал студии (не дебаг)220Mb (Cp1251; 1 000 000 строк) 2758.562927 ms 2312 ms 2500 ms 3187 ms На твоих данных тоже отрыв меньше. Java GCC 4.6.2 MS VS 2010 (дабл кликом по exe'шнику) Из-под визуал студии (не дебаг)57Mb (UTF-8; 1 000 000 строк) 1134.198872 ms 765 ms 796 ms 1375 ms54Mb (Cp1251; 1 000 000 строк) 1112.455888 ms 734 ms 796 ms 1344 ms "Твои данные" получил так: TextGen.java Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. Сравнение не совсем чесное. Если в java длина строки будет больше буффера - буффер увеличится (создастся новый массив, а значения из старого будут скопированны в новый). В С++ программе строка длинее буфера будет просто обрезана. (с utf-8 кодировкой эта C++ программа тоже работать не умеет.. просто байты) Всякие настройки C++ компилятора не крутил ибо не умею. Твой код маленько отрефакторил ReadFile.java Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. ReadFile.cpp Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. До того как порефакторил было также. Правда найти под виндой правильный аналог sys/time.h ума не хватило. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 10:24 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
avp.mk, у вас - смешанный бенчмарк. Он меряет и IO и аллокацию списков. Это создаёт некоторую путаницу. Мы не в состоянии делать выводы. У вас - однопоточное приложение поэтому вы можете детектировать раздельное время на эти две операции. Шаблон Files.readAllLines доступен в исходниках поэтому его тоже можно развалить на атомы и сделать отдельные счётчики по диску и работе со строками и списками. Если ваш код работает слишком быстро - то вы его запускаете многократно и меряете average. Если у вас два теста то вы запускаете их поочерёдно Test1, Test2, Test1, Test2 и тоже усредняете результаты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 12:20 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
maytonПостановка немного абсурдна. Если вам "прилетел" файл - то пускай улетает обратно. В продуктиве нет таких постановок. +! аффтару в конторе заняться нечем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 12:57 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
maytonavp.mk, у вас - смешанный бенчмарк. Он меряет и IO и аллокацию списков. Это создаёт некоторую путаницу. Мы не в состоянии делать выводы. Бенч как раз хороший, ровно то, что просил _автор_ топика. У меня такой же результат "Java vs C-код - ничья", при этом C код в режиме debug /без оптимизации/ значительно проигрывает Java. А вообще Assembler всех забивает с огромным отрывом ))). А мерить и нечего: IO - что C, что Java даст одинаковую скорость. Это целиком зависит от дисков и ОС. Последующая обработка - разделение на строки (по символу '\n') и парсинг ('\t'). Код на C _всегда_ будет в выигрыше, но скорее всего менее универсален/функционален. Выделение памяти - Java значительно быстрее (мерил лет 10 назад), но проблемы с GC. Если GC не работает (заранее правильное выделение памяти), то Java и C# уделывают C. Компактность хранения данных в памяти - C/C++ выигрывает с отрывом. На C/C++ можно хранить значительно компактнее, на Java классы более универсальны и нет возможности адресной арифметики (указателей) C. etc... Данные вещи вроде как очевидны исходя из архитектуры. Мерить смысла нет. Кому нечем заняться, могут пытаться написать корректный ))) бенчмарк и заняться холеваром. schwaСравнение i/o на java и на c/c++ в основном это замеры оверхеда от выделения памяти виртуальной машиной т.к. все массивы байт скопируются по N-раз пока дойдут до места, где java-разработчик может ими начать оперировать. IMHO Оверхид достаточно маленький. AFAIK: 1) На Java выделение памяти практически "бесплатно" с точки зрения CPU. Все проблемы с аллокацией проявятся только на стадии GC. Особенно в нормально нагруженном продакшене. Когда пара десятков юзеров будет разом eden область в куче засирать. 2) Тупое копирование строки операция крайне быстрая. Т.к. оптимизирована под CPU. Тут больше имеет проблема промахи предсказателя переходов и кеша. Без промахов, скопировать пару десятков байт дешевле, что с промахами проверить один символ на равенство \n' ))). Но это очень сильно тюнеть программу нужну. И ставить Intel VTune, что бы смотреть, какие конвейеры в процессоре затыкается. В данном случае, все исключительно зависит от качества JIT-компилятора. При ООП программирование и одинаковых классах, JAVA, скорее всего, даст более высокую скорость, чем C++. Вызов виртуального метода JIT-компилятор заинлайнить может, а C++ компилятор нет. Сравнивать C-код и Java-код очень сложно. Больно все разное. С-код без ООП скорее всего будет на порядки быстрее любого ООП-шного. Но и, скорее всего, менее функционален. Т.к. никто в здравом уме, не будет самопальную поддержку 100500 кодовых страниц реализовывать. Тут выбор: или скорость или универсальность. Ну и нормальный C-программисту и в голову не придет, для задачи "...просят вас что то посчитать в этом файле - что то найти..." 15579898 городить списки и затаскивать миллионно-строчный файл в память. Все "посчитают и найдут" просто проходом по байтовому массиву. ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 14:05 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Потому что код плюсов и код жабы не идентичен. String в жаве - более высокоуровневая сущность, чем char* Само io знамает одинаковое время: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. Результат: Read file 108 ms. Parse file: 1415ms Lins count= 1000000 На стандартных настройках gc. Тут надо сказать почему вышло такое время парсинга. В жабе в хотспоте размер класса,c учетом всех выравниваний, кратен 64байтам. На многопоточных программах это дает мегпреимущества. Это значит, что когда делается new String, то создается несколько обьктов суммарным обьемом кратным 64. Попытаемся прикинуть сколько обьектов создается и сколько они займут Естественно, приблизительно: Сами обьекты String - 1000000, внутри каждого String есть char[] -- тоже 1000000 инстансов. каждый стринг - считаем 64байта, каждый char - два байта, строка около 60символов, это 120 байт, плюс заголовок у каждого обьекта где-то 12 байт. Т.е., ближайшее большее кратное длине кешлайна -- 192байта. Таким образом, на каждый стринг на все его инстансы надо 256байт минимум. И если у нас EDEN меньше суммарного обьема всех этих данных, то очевидно, что копирования не избежать. Хотим быстро отпарсить 1М таких строк - выделите не менее 256мб EDEN. И это оценка снизу, т.е. на практике нужно больше. Проверим это. Запустим парсинг с параметрами -Xms3584m -Xmx3584m , получаем 759мс, против 1533мс. Уже лучше. Это раз. Два, как сказано выше, char* в сях и String не развнозначные классы. Чтобы сказать сколько символов в char*, надо затратить некоторое время, чтобы их подсчитать (и с учетом кодировки, побайтовая длина не подходит), а String тратит это время на этапе создания. Плюсы вообще, насколько знаю, не умеют работать с utf-8, в них есть wstring в которых 1 символ - 4 байта. C++11 вводит u16string, но на сегодня gcc который это может отктпилить, в стандартных репозиториях нет. Вообще же, в седьмой жаве убрали "некопируемость" данных из строк для того чтоб работал escape-анализ. Для быстрой работы с большми строками рекомендуют direct ByteBuffer и CharSequence. Если мы хотим аналогии с плюсами, действовать надо так -- сначала читаем все в ByteBuffer, после чего находим индексы всех \n и прибавляем к ним 1 - это будут указатели, аналог char*. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 16:11 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
ivanra1000000 строк - 1000000 раз будет создаваться и компилироваться Pattern, скорее всего, можно ускорить разбор, заготовив Pattern заранее.... не подтвержденные сведения, но похоже на правду: автор... В Java 7 разбиение на подстроки, в случае если шаблон состоит из одного символа, было оптимизировано в методе String.split. Всегда используйте этот метод для разбиения на подстроки в Java 7... (C) http://java-performance.com/ru/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 19:46 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
UP вот нашел задачу , которая не проходит на 11 тесте по времени ...его просто не хватает ... какие могут быть решения? https://acmp.ru/index.asp?main=task&id_task=41 На планете «Аурон» атмосфера практически отсутствует, поэтому она известна своими перепадами температур в различных точках. Известно, что эти перепады колеблются от -100 до 100 градусов. Нашим специалистам удалось выяснить значения температур в N точках этой планеты. К сожалению, эти значения вычислены с большими погрешностями, поэтому их решили округлить до целых чисел. Хотелось бы наглядно видеть участки с повышенной и пониженной температурой. Вам требуется помочь. Вы должны упорядочить температуры участков по неубыванию. Входные данные В первой строке входного файла INPUT.TXT задано натуральное число N - количество участков (N <= 10^6). Во второй строке через пробел записаны целые значения температур этих участков, не превосходящие 100 по абсолютной величине. Выходные данные В единственную строку выходного файла OUTPUT.TXT нужно вывести разделенные пробелом значения температур всех известных участков, которые должны следовать друг за другом в порядке неубывания. мое решение : Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. падает на 11 Time limit exceeded 2,145 7,9 Мб Менял на Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. падает на тесте 9 Memory limit exceeded 0,522 26 Мб Нужно найти быстрое чтение , запись в файл + быстрый разбор строки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 10:30 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1, авторВ качестве критерия ранжирования лучших попыток служит размер кода закачиваемой программы. OMFG... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 10:45 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1, Убери конкатенацию строк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 10:54 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczAtum1, авторВ качестве критерия ранжирования лучших попыток служит размер кода закачиваемой программы. OMFG... да, все честно ) самые быстры и короткие Это https://acmp.ru/index.asp?main=bstatus&id_t=41 Python и С++ как правило ... по всем задачам .. что говорит о выразительности языка ... его скорости итд ... для олимпиад самое то ... Правда меня иногда ставит в замешательство когда находятся люди предложившие решение на java в 135 строк - вопрос только один как ? как они такое смогли сжать код ???? по некоторым задачам . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 10:55 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1, flush() не нужен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 10:56 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1что говорит о выразительности языка ... Питон он вообще заточен под подобные задачи. С плюсами просто всё понятно. А в Java у нас ООП. Только объекты и методы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 11:00 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczAtum1, Убери конкатенацию строк. 201 значение это долго? в каком месте ? я уже и строку пытался читать посимвольно(нахожу число - добавляю в массив ) все равно медленно . :( ps офф https://acmp.ru/index.asp?main=task&id_task=1 вопрос как : получить 135 ? ЗАДАЧА №1 A+B (Время: 1 сек. Память: 16 Мб Сложность: 2%) Требуется сложить два целых числа А и В. Входные данные В единственной строке входного файла INPUT.TXT записано два натуральных числа через пробел, не превышающих 109. Выходные данные В единственную строку выходного файла OUTPUT.TXT нужно вывести одно целое число — сумму чисел А и В. размер 300 Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 11:00 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38567528&tid=2123129]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
103ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
71ms |
get tp. blocked users: |
2ms |
| others: | 198ms |
| total: | 416ms |

| 0 / 0 |
