Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>И счет идет на миллисекунды. PD>>Их надо конвертировать в XML и обратно B>Наличие такой комбинации вызывает улыбку и полное непонимание зачем при таком ударе по производительности в целом приходится тюнить такие мелочи как создание объектов и GC?
Еще раз объясняю. Есть некий работающий продукт. В него надо встроить XML преобразование, о котором я писал. Оно отнимет время, в результате чего качество будет ухудшено (так как собственно обработка получит меньше времени, а там лимит по времени), и объяснить заказчику, почему мы начали улучшение продукта с потери качества, не очень-то легко. Поэтому это время надо свести к минимуму. Да, это время несравнимо с временем собственно обработки, намного меньше, но это несущественно.
О каком ударе по производительности ты говоришь — не понял.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Pavel Dvorkin, Вы писали:
C>Бери профилятор и смотри где там у тебя bottleneck'и.
А что толку ? Там сейчас Xerces SAX стоит, не буду же я его переписывать!
C>Думай тогда как оптимизировать работу с XML — это будет самая тормозная часть.
А вот здесь был бы благодарен за любые советы. SAX можно и убрать, но на что заменить, чтобы было быстрее ? JAXB/JiXB будет быстрее или наоборот ?
В общем, суть задачи предельно проста. Есть XML, заведомо валидный, проверка не требуется. Есть XSD, описывающий его схему, тоже валидный. Необходимо из XML создать экземпляр класса Java и обратно. И как можно быстрее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>О каком ударе по производительности ты говоришь — не понял.
У тебя будут основные тормоза на разборе XML. Да еще ты вроде бы начал JAXB использовать.
Если нужна скорость — используй быстрый парсер XML (лучше SAX или pull-парсер) и делай оптимизированый ручной mapping.
На фоне этого у тебя экономия на создании объектов даже измерима не будет.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>О каком ударе по производительности ты говоришь — не понял. C>У тебя будут основные тормоза на разборе XML. Да еще ты вроде бы начал JAXB использовать.
Еще не начал. Не стоит пробовать ?
C>Если нужна скорость — используй быстрый парсер XML (лучше SAX или pull-парсер) и делай оптимизированый ручной mapping.
Так сейчас и делается. Xerces SAX и ручная разборка. Про pull-парсеры не в курсе, если можешь, дай линк.
C>На фоне этого у тебя экономия на создании объектов даже измерима не будет.
Я, как тот утопающий, хватаюсь за любую соломинку. Меня тут упорно убеждали, что выделение памяти в Яве несравнимо по времени с, например, обработкой строк. Я в теории вполне согласен с этим, может, это и верно, но...
Сделал я следующий тест. В SAX заменил реальный content handler на пустой handler. Иными словами, SAX все делает как обычно, разбирает XML, парсит текст, вызывает у меня startDocument и прочее, только я в ответ никакие экземпляры не создаю и поля не заношу (а там, напоминаю, один числа и текстовые строки в конце концов). Так вот, время составляет примерно 50% от настоящего. Иными словами, 50% времени уходит на создание объектов (а может, на уничтожение потом ?) и присваивание значений полям.
И еще одно я сделал. Нашел некий SAX piccolo (http://piccolo.sourceforge.net/), который, как там утверждается, быстрее Xerces. Попробовал его. В среднем быстрее, но на некоторых образцах раза в 3-4 медленнее, причем нестабильно : пропускаю тесты один раз — медленнее, еще раз — нормально. Из-за чего ? Я могу отнести это только на какие-то проблемы с выделением/освобождением памяти, поскольку все остальное без изменений.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>О каком ударе по производительности ты говоришь — не понял. C>>У тебя будут основные тормоза на разборе XML. Да еще ты вроде бы начал JAXB использовать. PD>Еще не начал. Не стоит пробовать ?
Стоит. Попробуй и посмотри какое замедление будет. Еще на XML Binding из http://javolution.org/ можно посмотреть.
C>>Если нужна скорость — используй быстрый парсер XML (лучше SAX или pull-парсер) и делай оптимизированый ручной mapping. PD>Так сейчас и делается. Xerces SAX и ручная разборка. Про pull-парсеры не в курсе, если можешь, дай линк.
Xerces известен как достаточно большой тормоз, так что может иметь смысл взять альтернативный парсер.
Про pull-парсер — поищи по слову StAX.
PD>Сделал я следующий тест. В SAX заменил реальный content handler на пустой handler. Иными словами, SAX все делает как обычно, разбирает XML, парсит текст, вызывает у меня startDocument и прочее, только я в ответ никакие экземпляры не создаю и поля не заношу (а там, напоминаю, один числа и текстовые строки в конце концов). Так вот, время составляет примерно 50% от настоящего. Иными словами, 50% времени уходит на создание объектов (а может, на уничтожение потом ?) и присваивание значений полям.
Можно пример? Кстати, ты, надеюсь, HotSpot-компиляцию не считаешь?
PD>И еще одно я сделал. Нашел некий SAX piccolo (http://piccolo.sourceforge.net/), который, как там утверждается, быстрее Xerces. Попробовал его. В среднем быстрее, но на некоторых образцах раза в 3-4 медленнее, причем нестабильно : пропускаю тесты один раз — медленнее, еще раз — нормально.
Точно, HotSpot-компиляцию считаешь. Дело в том, что в Java байт-код транслируется в машинный код после того, как он будет работать в режиме интерпретации некоторое время. Порог компиляции зависит от опций JVM: серверная JVM имеет более высокий порог и использует большее количество оптимизаций (из-за чего программы под ней медленно запускаются, но потом работают быстрее), клиентская JVM имеет более низкий порог (т.е. она оптимизирована на более быстрый запуск).
На микротестах оно может дать очень существенный разброс. Например, мой сервер запускается за 3.5 секунды на клиентской JVM и более 6 секунд на серверной. Зато пропускная способность сервера на серверной JVM получается на 20% выше (из-за большего количества оптимизаций).
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>О каком ударе по производительности ты говоришь — не понял. C>>>У тебя будут основные тормоза на разборе XML. Да еще ты вроде бы начал JAXB использовать. PD>>Еще не начал. Не стоит пробовать ? C>Стоит. Попробуй и посмотри какое замедление будет. Еще на XML Binding из http://javolution.org/ можно посмотреть.
Спасибо за ответ. Не буду
C>>>Если нужна скорость — используй быстрый парсер XML (лучше SAX или pull-парсер) и делай оптимизированый ручной mapping. PD>>Так сейчас и делается. Xerces SAX и ручная разборка. Про pull-парсеры не в курсе, если можешь, дай линк. C>Xerces известен как достаточно большой тормоз, так что может иметь смысл взять альтернативный парсер.
Можешь порекомендовать какой- то ?
C>Про pull-парсер — поищи по слову StAX.
OK, посмотрю.
PD>>Сделал я следующий тест. В SAX заменил реальный content handler на пустой handler. Иными словами, SAX все делает как обычно, разбирает XML, парсит текст, вызывает у меня startDocument и прочее, только я в ответ никакие экземпляры не создаю и поля не заношу (а там, напоминаю, один числа и текстовые строки в конце концов). Так вот, время составляет примерно 50% от настоящего. Иными словами, 50% времени уходит на создание объектов (а может, на уничтожение потом ?) и присваивание значений полям. C>Можно пример?
Увы, нельзя, код показать не могу. Могу показать только псевдо-хэндлер, но там решительно ничего нет, кроме вызова setContentHandler и переписанного parse.
>Кстати, ты, надеюсь, HotSpot-компиляцию не считаешь?
PD>>И еще одно я сделал. Нашел некий SAX piccolo (http://piccolo.sourceforge.net/), который, как там утверждается, быстрее Xerces. Попробовал его. В среднем быстрее, но на некоторых образцах раза в 3-4 медленнее, причем нестабильно : пропускаю тесты один раз — медленнее, еще раз — нормально. C>Точно, HotSpot-компиляцию считаешь. Дело в том, что в Java байт-код транслируется в машинный код после того, как он будет работать в режиме интерпретации некоторое время.
Из чего следует, что это здесь ни при чем. Дело в том, что пропускаю я набор из 200 тестов, и замедление (случайное) может быть на 100-м или 150-м, в общем, далеко не в начале набора. По логике вещей, там все уже откомпилировано к этому моменту.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Так сейчас и делается. Xerces SAX и ручная разборка. Про pull-парсеры не в курсе, если можешь, дай линк. C>>Xerces известен как достаточно большой тормоз, так что может иметь смысл взять альтернативный парсер. PD>Можешь порекомендовать какой- то ?
Если смотреть на это: http://www.xml.com/pub/a/2007/05/09/xml-parser-benchmarks-part-1.html , то http://woodstox.codehaus.org/ самый быстрый.
C>>Точно, HotSpot-компиляцию считаешь. Дело в том, что в Java байт-код транслируется в машинный код после того, как он будет работать в режиме интерпретации некоторое время. PD>Из чего следует, что это здесь ни при чем. Дело в том, что пропускаю я набор из 200 тестов, и замедление (случайное) может быть на 100-м или 150-м, в общем, далеко не в начале набора. По логике вещей, там все уже откомпилировано к этому моменту.
Вот как раз это больше всего ПОХОЖЕ на включение HotSpot'а. Каждый тест в отдельности будет запускаться в режиме интерпретации, а где-то в середине тестов включается компиляция какого-нибудь большого куска кода.
Если хочешь протестировать скорость правильно — выполни сначала каждый тест раз 1000 в цикле, а только потом измеряй сколько оно займет.
Здравствуйте, Cyberax, Вы писали:
C>Вот как раз это больше всего ПОХОЖЕ на включение HotSpot'а. Каждый тест в отдельности будет запускаться в режиме интерпретации, а где-то в середине тестов включается компиляция какого-нибудь большого куска кода.
Еще подумал — ты это можешь еще ловить полные циклы сборки GC (когда он собирает мусор в старом поколении). Тогда на время и положение паузы должны влиять опции GC (попробуй включать/выключать конкуррентный GC и покрутить настройки объема кучи).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>О каком ударе по производительности ты говоришь — не понял.
Исследование используемого XML движка и его оптимизация под проект могут дать, к примеру 1% выигрыша CPU, при том что какой-либо тюнинг в создании объектов не более чем 0.1%. Просто работы можно проделать достаточно много, придумывая хитроумные инициализации. Но при этом эффект будет пшиковый.
Здравствуйте, Cyberax, Вы писали:
C>Если нужна скорость — используй быстрый парсер XML (лучше SAX или pull-парсер) и делай оптимизированый ручной mapping.
Поидее прегенеренные сериализации вроде JAXB/JiBX должны быть быстрее.
Здравствуйте, Blazkowicz, Вы писали:
B>Исследование используемого XML движка и его оптимизация под проект могут дать, к примеру 1% выигрыша CPU, при том что какой-либо тюнинг в создании объектов не более чем 0.1%.
Хотелось бы верить...
>Просто работы можно проделать достаточно много, придумывая хитроумные инициализации. Но при этом эффект будет пшиковый.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Cyberax, Вы писали:
C>>Если нужна скорость — используй быстрый парсер XML (лучше SAX или pull-парсер) и делай оптимизированый ручной mapping. B>Поидее прегенеренные сериализации вроде JAXB/JiBX должны быть быстрее.
Разошлись вы тут с Cyberax во мнениях. Это вы, специалисты в Яве. Что же мне, дилетанту в ней, делать ?
Здравствуйте, Blazkowicz, Вы писали:
B> тюнинг в создании объектов не более чем 0.1%
Зато тюнинг GC может дать на много больше. Для начала советую включить опции "-XX:+PrintGCDetails -XX:+PrintGCTimeStamps". Или можно включить "-XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime". Я не знаю какая норма отношения StoppedTime/ConcurrentTime, но если оно больше 5% то стопудово можно тюнить.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Разошлись вы тут с Cyberax во мнениях. Это вы, специалисты в Яве. Что же мне, дилетанту в ней, делать ?
А тебе взять, да померять оба варианта на своей иерархии. Работы на день максимум.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Зато тюнинг GC может дать на много больше. Для начала советую включить опции "-XX:+PrintGCDetails -XX:+PrintGCTimeStamps". Или можно включить "-XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime". Я не знаю какая норма отношения StoppedTime/ConcurrentTime, но если оно больше 5% то стопудово можно тюнить.
Ну, о чем собственно уважаемому Павлу Дворкину и твердят с начала топике. Что оптимизации GC через параметры будет гораздо эффективней всяких выдумок на уровне кода.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хотелось бы верить... PD>Может быть...
Вам одно и тоже повторило уже несколько человек, почему бы уже не прислушаться? Может эксперту в Java — Брайану Гетцу — поверите? Здесь Re[3]: хочу невозможного
давал две ссылки на его статьи именно про JIT-компиляцию в JVM и тщетные попытки оптимизации при ее наличии (там же можно найти статьи про GC и избыточность оптимизации аллокации/деаллокации в условии развитого GC).
Здравствуйте, Blazkowicz, Вы писали:
PD>>Разошлись вы тут с Cyberax во мнениях. Это вы, специалисты в Яве. Что же мне, дилетанту в ней, делать ? B>А тебе взять, да померять оба варианта на своей иерархии. Работы на день максимум.
JAXB работает поверх SAX. SAX-имплементацию можно менять, т.е. если известно, что A быстрее, чем B на тех данных, которые надо будет обрабатывать в приложении, то нужно подставить A (через endorsed или как там). JAXBу это будет прозрачно незаметно.
а вот ручной маппинг имхо следует писать только в том случае, если есть уверенность довести его до уровня гарантированного превышения скорости работы того же JAXB.
довести его за день — малореально
Здравствуйте, Blazkowicz, Вы писали:
B>А тебе взять, да померять оба варианта на своей иерархии. Работы на день максимум.
Ага. Только померить, как сказано выше уже несколько раз, то есть с учетом JIT-компиляции, а то он опять запустит по одному тесту или каждую итерацию теста в виде запуска новой виртуалки — и опять придет сюда говорить, что 50% выигрыша.
Здравствуйте, rsn81, Вы писали:
R>Ага. Только померить, как сказано выше уже несколько раз, то есть с учетом JIT-компиляции, а то он опять запустит по одному тесту или каждую итерацию теста в виде запуска новой виртуалки — и опять придет сюда говорить, что 50% выигрыша.
А нельзя ли прочитать внимательно, что я написал, прежде чем второй раз вольные фантазии городить ? Вот здесь, в конце.
Из чего следует, что это здесь ни при чем. Дело в том, что пропускаю я набор из 200 тестов, и замедление (случайное) может быть на 100-м или 150-м, в общем, далеко не в начале набора. По логике вещей, там все уже откомпилировано к этому моменту.
P.S. Вообще, если тебя раздражают мои вопросы — можно и не отвечать вообще. Я не флейма ради эту дискуссию затеял, мне реальный ответ нужен.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Разошлись вы тут с Cyberax во мнениях. Это вы, специалисты в Яве. Что же мне, дилетанту в ней, делать ? B>А тебе взять, да померять оба варианта на своей иерархии. Работы на день максимум.
Ох, не знаю. SAXB свои собственные классы создает, и мне, видимо, надо именно их использовать, так ? или нет ? "Ручная" реализация классов уже создана (не мной), используется в SAX Xerces, и там много чего еще понавешено, к делу не относящегося.
