tinyxml

[killerbot]

I think recently we defined to use it stl string variant in the makefile.am,

but was it specified in the makefile.am of every using library ? Cause I think the headers itself will not define it on the inside ?

Next to that, shouldn't we do a similar thing then for the cbp' files ? At this time such a define on workspace level would come in handy ;-)

[oBFusCATed]

And what is the benefit from this change?
As far as I know tinyxml becomes slower and uses more memory when using STL (I have memory related problems related to tinyxml, thread search and big output files from valgrind).
Biplap can you elaborate on the reason for the change?

[thomas]

Are you sure? This cannot really work, since we use custom wxString wrappers (tinywyuni.h if I recall correctly) to interface TinyXML (unless wxWidgets has constructors for std::string, and an operator std::string).

On a different note, if you feel like playing around with TinyXML, there is TinyXML2 available in the mean time. Same author, slightly different, but similar API, and allegedly much more efficient and smaller. Though I've not had time to test it.

[oBFusCATed]

TinyXML2 won't solve my problems (it is said to use 2x or something like that less memory).
Two of them, I now remembered the details:
1. Loading the xml file produced by valgrind for a Codeblocks run is almost impossible. This file is used to fill the results in the logger. This happens, because the Valgrind plugin is using a DOM parser and this parsers allocates too much memory (1-2-4gb). Using a SAX type parser probably will be faster and will use less memory, but I couldn't find a SAX xml lib I like, nor do I have time now for fixing this.

2. Searching with ThreadSearch in the trunk/src/ for all files (*.cpp;*.h;*.xml) when there is a large xml file generated by Valgrind finishes with me killing codeblocks.
    I don't know why ThreadSearch tries to open the file in an editor before searching in it.

p.s. Thomas are you talking to me or to Killerbot?

[thomas]

p.s. Thomas are you talking to me or to Killerbot?

Was referring to Killerbot's statement that this build configuration had been changed. In my opinion, this couldn't even work (apart from the memory issues that you've pointed out).

Though in the mean time, I've verified the code in tinywxuni.cpp. It actually uses a char* for reading, and TinyXML's CStr() function for writing, so (unintentionally) I've written code that works in either configuration.
I was under the assumption that these expected wxString references, but these are only assigned in the application, not the utility function.

About TinyXML2, my point was that rather than tweaking some config value that presumably does little good, one could replace TinyXML with its newer version, if there's a desire to make it faster (or whatever other reason).

[MortenMacFly]

On a different note, if you feel like playing around with TinyXML, there is TinyXML2 available in the mean time. Same author, slightly different, but similar API, and allegedly much more efficient and smaller. Though I've not had time to test it.

I am using it already in other projects (and even already contributed a tiny piece to the source ;-)). Its very neat, hence has (for me) one major drawback: You cannot pinpoint an error to a line in the XML file. For our purposes its not very nice, case you'll be not able to tell the user where in the config file the error occurred. That's also why I left the C::B SDK untouched so far.

[Jenna]

I loaded a nearly 1GB Valgrind xml-file (C::B run) with 9099 and 9120 and the time needed to load is nearly the same (about 50 sec), memory footprint for 9120 is a little bit larger (7.4 GB against 7.2 GB not swappable memory, 8.6 GB against 8.6 GB virtual memory).
After searching for "test" in all *.cpp, *.h amd *.xml files (including the 1 GB Valgrind-file) both use 14.1/14.1 and 12.6/12.8 GB (same difference to just loaded xml file as before).
While searching they used up to 18.5 GB of memory and that will surely break systems with less real memory (32 GB).

The fact that so much memory is in use after the search is probably a problem.

But I do not see a sigificant difference in both revisions (with and without use of STL-string in tinyxml).

[oBFusCATed]

But I do not see a sigificant difference in both revisions (with and without use of STL-string in tinyxml).

I don't think ThreadSearch is using tinyxml, during searching. I think that it opens an editor, so the used memory is coming from Scintilla.