Subject: Re: Why We Should Use the STL (fwd)
From: Aaron Lehmann (aaronl@vitelus.com)
Date: Sun Jun 04 2000 - 11:50:44 CDT
Well, I'm pleasently suprized that an AbiWord developer would even suggest
such a contraversial change.
I agree 100%. Speed is very important, even in desktop programs. It is
pointless to slow down some parts of the program by 23 times just because
of a fear of templates.
Another issue I would like to raise is standards. The point of STL is
having a standard so that applications do not have to implement their own,
mediocre, simple types. This is what AbiWord has done. By all means,
AbiWord should use the standard, not only for speed, but so that C++
developers don't have to learn yet another type library. Using STL would
mean that we wouldn't have to maintain or support the UT_* classes,
because they would be replaced by faster, better, more standard
equivilents.
I really hope this doesn't get vetoed by the luddites ( :) ) on this list.
Now, who's going to write this huge patch? ;-)
Aaron Lehmann
On Sun, 4 Jun 2000, sam th wrote:
> ---------- 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 - 11:50:49 CDT