pugixml и tinyxml

pugixml

http://pugixml.files.wordpress.com/2010/10/parsing-performance-for-terrover-x...

http://pugixml.files.wordpress.com/2010/10/parsing-performance-for-terrover-x...

][м, почему такой разительный результат, неужели tinyxml индусы писали?

а где сравнение потребления памяти? Может там зеркальная картинка? И разбор какого-нибудь open-документа отправит твой комп в легкий нокаут? :)

http://pugixml.files.wordpress.com/2010/10/dom-memory-comparison-for-terrover...

сделать очень быстрый парсер с большим кол-вом аллокаций памяти, хотя бы и на пуле, малореально

http://pugixml.files.wordpress.com/2010/10/parsing-performance-for-terrover-x...

Было бы странно, если бы в блоге pugixml победу одержал tinyxml.

По теме, использую tinyxml для описания ресурсов и уровней. Проблем со скоростью не замечал. Работать с tinyxml достаточно просто.

Было бы странно, если бы в блоге pugixml победу одержал tinyxml.

было бы странным, если б там специально «засудили» именно tinyxml

По теме, использую tinyxml для описания ресурсов и уровней. Проблем со скоростью не замечал.

я выбрал rapidxml, т.к. по личным сравнениям он быстрее tinyxml и куда более «tiny»

Проблем со скоростью не замечал

Ну еще бы, ее и не заметишь, пока количество строк исчисляется десятками, а вот как в ваших уровнях количество объектов начнет переползать за тысячу (травка например, и позиция каждой из них), загрузка уровней начнет ощущаться. Вот тут и будет видно, что быстрее из библиотек.

я выбрал rapidxml, т.к. по личным сравнениям он быстрее tinyxml и куда более «tiny»

Как у него с кроссплатформенностью?

Ну давайте проведем тесты. Предложите сложный и тяжелый на ваш взгляд xml и методику тестирования, а я потестирую tinyxml.

а вот как в ваших уровнях количество объектов начнет переползать за тысячу (травка например, и позиция каждой из них), загрузка уровней начнет ощущаться.

Сдается мне, что загрузка одного png или jpeg скажется сильнее, чем парсинг xml с тысячей объектов по десятку атрибутов в каждом.

Как у него с кроссплатформенностью?

#if !defined(RAPIDXML_NO_STDLIB)
    #include <cstdlib>      // For std::size_t
    #include <cassert>      // For assert
    #include <new>          // For placement new
#endif
#include <exception>    // For std::exception

вот и все что он требует для работы - только стандартные хедера, собс-но сам парсер и представляет собой один хедер

вот и все что он требует для работы - только стандартные хедера, собс-но сам парсер и представляет собой один хедер

Угу уже посмотрел. Но пока не увидел ни одной причины для отказа от tinyxml в пользу rapidxml.

Сдается мне, что загрузка одного png или jpeg скажется сильнее, чем парсинг xml с тысячей объектов по десятку атрибутов в каждом.

Вы ошибаетесь, это может быть одна картинка травки, и один меш клонированный хоть пять тысяч раз, на все это включается инстансинг геометрии, так что это не повлияет ни на фпс игры, ни на скорость загрузки (один меш и картинка), а вот 5 тысяч записей читаться будут долго :)

Ну давайте проведем тесты. Предложите сложный и тяжелый

Предлагаю такую структуру:

<?xml version="1.0" encoding="UTF-8" ?>
<scene formatVersion="1.0.0" generator="Test">
<resourceLocations>
<resourceLocation type="FileSystem" name="./Data" />
</resourceLocations>
<nodes>
<node name="node_0" id="0">
<position x="0.0" y="0.0" z="0.0" />
<rotation qw="0.0" qx="0.0" qy="-90.0" qz="0.0" />
<scale x="1.0" y="1.0" z="1.0" />
<entity name="entity_0" meshFile="test.mesh" castShadows="false">
<subentity index="0" materialName="terrain.material" />
</entity>
</node>
</nodes>
</scene>

php-генератор файла (файл generate.xml должен существовать, с правами на запись):

<?php
$file = "generate.xml";
$filebegin = '<?xml version="1.0" encoding="UTF-8" ?>
<scene formatVersion="1.0.0" generator="Test">
<resourceLocations>
<resourceLocation type="FileSystem" name="./Data" />
</resourceLocations>
<nodes>';
$fileend = '</nodes>
</scene>';
if(is_file($file)){
$fileopen=fopen($file,"a");
fwrite($fileopen,$filebegin);
$gennumber = 6001;
$i;
for ($i = 0; $i <$gennumber; $i++){
$addobj = '<node name="node_'.$i.'" id="'.$i.'">
<position x="'.$i.'" y="'.$i.'" z="0.0" />
<rotation qw="0.0" qx="0.0" qy="-90.0" qz="0.0" />
<scale x="1.0" y="1.0" z="1.0" />
<entity name="entity_'.$i.'" meshFile="test.mesh" castShadows="false">
<subentity index="0" materialName="terrain_'.$i.'.material" />
</entity>
</node>';
fwrite($fileopen,$addobj);
}
fwrite($fileopen,$fileend);
fclose($fileopen);
}
?>

вернее 6000 ровно если от нуля.

Либо отсюда берем сгенерированный-хмл файл (6001-на нода, структура таже что выше предлагал).

Взял готовый файл. Читал все атрибуты. Что бы компилятор их выбросил, я их суммировал, строки просто читал и считал их кол-во.
Запустил под android на htc desire.

Результаты пяти запусков приложения (микросекунды):
2075805
2033020
2020417
2040314
2042359

Отлично, кто затестит pugixml?

wota затести rapidxml если не влом.

Чем/как время считал до такой точности?

не, вы просто строки целиком читали, не входя в группы, не парся конкретные имена и т.п.

насчет цифр - это процессор еще не успевает поднять частоту, если руками выставить - 3-4мс

не входя в группы, не парся конкретные имена и т.п.

парсится все сразу, но сейчас добавлю и обход

вообще это не показатель, один программист напишет в while, другой в for итп, а нужно что бы у обоих методы парсинга были одинаковы (с учетом лишь различия библиотечных методов), иначе разлет во времени неизбежен. Ну и да, железо конечно в идеале одно и тоже нужно. Короче гнилая затея...

#include <cstdio>
#include <fstream>
#include <sys/timeb.h>
#include "rapidxml.hpp"
using namespace rapidxml;
using namespace std;

static void print_node( string& out, xml_node<>* node ) {
	out += "\033[1m\033[32m";
	out += node->name();
	out += "\033[0m:\n";

	auto attr = node->first_attribute();
	while( attr ) {
		out += attr->name();
		out += '=';
		out += attr->value();
		out += '\n';
		attr = attr->next_attribute();
	}
}

int main() {

	// 1. READ FILE

	ifstream f( "generate.xml" );
	f.seekg( 0, ios::end );
	size_t size = f.tellg();

	char buf[ size+1 ];
	f.seekg( 0, ios::beg );
	f.read( buf, size );
	buf[ size ] = 0;

	// 2. PARSE XML

	timeb tp;
	ftime( &tp );
	long start = 1000L * tp.time + tp.millitm;

	string out;

	xml_document<> doc;
	doc.parse<0>( buf );

	auto nodes = doc.first_node( "scene" )->first_node( "nodes" );
	auto node = nodes->first_node();
	while( node ) {
		print_node( out, node );

		auto subnode = node->first_node();
		while( subnode ) {
			print_node( out, subnode );
			subnode = subnode->next_sibling();
		}

		node = node->next_sibling();
	}

	ftime( &tp );
	long end = 1000L * tp.time + tp.millitm;

	// 3. PRINT RESULT

	printf( out.c_str() );
	printf( "%.3fsec\n", ( end - start ) / 1000. );
}

раза в полтора дольше выполняется (8-10мс), но это из-за набивания строки out

а нужно что бы у обоих методы парсинга были одинаковы

нужна четкая задача, тогда не важно кто как пишет

железо конечно в идеале одно и тоже нужно.

код есть - можешь прогнать у себя

угу, вот яи говорю, хрень все это, пока не составим единый класс, с минимальным различием для конкретной либы.

тогда не важно кто как пишет

Да ладно, может я индус ифоми до конца файла парсить буду :)
вообщем ладно, я решил либо rapidxml, либо pugixml использовать, скорее всего первое (кстати спасибо за инфу, о его существовании я не знал).

Чем/как время считал до такой точности?

    struct timeval tp;
    struct timezone tzp;
    static int secbase = 0;
    ::gettimeofday(&tp, &tzp);
    if (!secbase)
    {
        secbase = tp.tv_sec;
        *time = tp.tv_usec;
        return;
    }
    time = (tp.tv_sec - secbase) * 1000000 + tp.tv_usec;

Отлично, кто затестит pugixml?

Позже прикручу rapidxml и прогоню этот же тест на том же железе.