Subject: Why We Should Use the STL (fwd)
From: sam th (sam@uchicago.edu)
Date: Sun Jun 04 2000 - 03:21:10 CDT
---------- Forwarded message ----------
Date: Sun, 4 Jun 2000 02:45:51 -0500 (CDT)
From: sam th <sam@uchicago.edu>
To: abiword developer list <abiword-dev@abisource.com>
Subject: Why We Should Use the STL
Now, I realize that this is going to cause controversy, but I hope we
don't need to have flames.
Currently, we use none of the STL. This is becuase we have been under the
impression that templates were not well-enough supported on all the
platforms we use. However, this is untrue.
As far as I know, the major compilers used for AbiWord are gcc (for linux,
be and qnx), metroworks (for mac) and VC++, borland and gcc (for
win32). every one of these compilers supports templates. As evidence of
this, I offer the list of supported compilers on
http://www.stlport.org/doc/platforms.html Every compiler we use (and lots
of others) are listed. If I have left out any compilers, please let me
know.
as to why we should use the STL, the reason is: it is lots faster.
I discovered this running a simple test of UT_Vector vs vector<>. If this
test is fatally flawed let me know, and I will retract everything. But
here goes.
I ran the following code for both UT_Vector and vector<int*>
void main()
{
for (int i=1; i<=1000; ++i)
{
#if 0
UT_Vector vec;
for (int j = 0; j<10000; ++j)
{
vec.addItem(&j);
if(j%100 == 0)
cout << j << " ";
}
vec.getItemCount();
#else
vector<int*> vec;
for (int j = 0; j<10000; ++j)
{
vec.push_back(&j);
if(j%100 == 0)
cout << j << " ";
}
vec.size();
#endif
}
cout << "\n\n\n\n\n\n\n\n\n\n\n\n";
}
Here's the output from time:
with UT_Vector
56.76user 1.84system 1:07.21elapsed 87%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (97major+29012minor)pagefaults 0swaps
With STL vector<int*>
2.20user 0.33system 0:05.06elapsed 49%CPU (0avgtext+0avgdata
0maxresident)k 0inputs+0outputs (100major+27014minor)pagefaults 0swaps
In other words, the STL implementation was about 26.25 times faster. When
you take out the output, the change is even more dramatic. The speed
factor increases to about 33.97 times faster for STL.
There is one potential drawback to the STL - it's pretty big. The STL
implementation of this simple program was 71k, or 72% larger. However,
this is not that much of a size increase, and AbiWord has room to
spare. We are the smallest word processor I have ever seen, and can
afford a few hundred k.
I realize that free software in general has been unfriendly to c++, and
it's advanced features especially. But in the face of that kind of speed
difference, I can't see not at least considering a change.
sam th
sam@uchicago.edu
http://sam.rh.uchicago.edu
And yes, I do know that premature optimization is the root of all evil.
------------ Output from gpg ------------
gpg: Good signature from "Sam Tobin-Hochstadt <sytobinh@uchicago.edu>"
This archive was generated by hypermail 2b25 : Sun Jun 04 2000 - 03:22:16 CDT