Re: template size and speed
charles.lobo@gmail.com wrote:
James Kanze wrote:
I tried using list<int>, list<double>, list<MyClass> and list<MyClass2>
in both types of lists.
Both the code sizes grow as shown below:
mytpl.exe:
With 1 type of list: 22,016
With 4 types of lists: 29,184
nonstd.exe
With 1 type of list: 36,864
With 4 types of lists: 45,056
I am measuring exe size so maybe it's not the best way.
Generally not. There are at least two things which can cause it
to be "false": parts of the standard library implementation
might be in a dynamically linked object, and so not be in the
..exe (not typically the case for templates, of course), and
unless the .exe has been stripped, it contains symbolic
information as well, so if your naming convention results in
longer names, the .exe will be larger.
But of course, the real question is: what size matters to you.
The size of the .exe is an accurate measurement of the space
your program takes on the disk. Unix has a utility, size, which
will indicate the sizes of the various segments that are loaded
(code, data, etc.). But of course, neither indicate much about
the size of the memory footprint of the program, which is often
the most important issue.
But the template list is still smaller than the non-template
version. Maybe this is the overhead of the virtual function
you mention.
Perhaps, coupled with the fact that the compiler is able to
merge much of the template code.
[...]
I measured timing by running a timer app on the generated exe's (again
maybe not the best way):
Again, it depends on what time matters. I usually measure CPU
time for such things -- it's what I get from the clock()
function under Unix, but I don't know how to get it under
Windows.
Also, you should run timing tests multiple times, to see if they
are repeatable.
Concerning your tests without templates: you do not use virtual
functions, I can't explain why the resulting code is larger, but
I don't see any virtual function calls in the code you posted,
so it's not surprising that the code is faster (or at least as
fast) than the template version. On the other hand, I would
expect it to be somewhat smaller. The main difference
that I see, however, is that there is an unchecked downcast in
the non-template version, which in production code will almost
surely result in undefined behavior in the long.
(I'm not sure what's going on internally, however. You have two
dynamic allocations for each new node in the non-template
version, which doesn't make sense if you have an IntElem type.
And of course, wouldn't be the case in a template implementation
either.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]