After following this thread, I'm beginning to think Stata Corp. ought to
offer a new "flavor" of Stata, say Stata NG (nongraphical), which has all
the new commands, etc of Stata 8, yet retains the simpler (but still very
serviceable) graphing characteristics of Stata 7. On the other hand, if the
major differnence betwen Stat 7 and 8 is the graphics, I'm not sure I really
want to upgrade.
Al Feiveson
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Thursday, January 16, 2003 12:07 PM
To: [email protected]
Subject: Re: st: Speed issues with Stata 8
Fred Wolfe <[email protected]> asked about Stata 8's speed in
two contexts:
1. -use- and -merge-
2. -graph-
Bill answered (1), so let me address (2).
Is Stata 8 slower drawing graphs?
---------------------------------
The short answer is yes, but it will get faster and we hope the time cost is
worth the results and flexibility.
What changed about graphics in Stata 8?
---------------------------------------
Everything.
Graphics are built on the new object oriented facilities in Stata 8.
Graphics
is largely programmed in ado-code, though time-critical facilities (such as
rendering thousands of points), are programmed in C and exposed to
ado-programmers through new graphics device interface (GDI) commands.
How does that affect speed?
---------------------------
In Stata 8 there is a fixed overhead when drawing a graph that is
independent
of dataset size (but with by() graphs and matrix graphics is dependent on
the
number of by groups or matrix cells). This overhead is primarily associated
with creating the objects of which all graphs are now composed. The benefit
of this organization is the flexibility you see in the new graph commands
and
the unprecedented ability of graphics ado programmers to create new graphs
and
graph commands.
How will graphics get faster?
-----------------------------
Some of the more time-consuming programs that are now written in ado-code
can
be converted into internal C. Some of this was built into the graphics
system
when designed and some additional conversion was done before Stata 8
shipped.
This conversion does come at a price -- features are more difficult to
extend once they are committed to internal C code and some flexibility is
lost.
Based on our own testing we are currently doing some additional conversions
right now, but we want to get feedback from users before internalizing
programs that only marginally affect speed.
-- Vince
[email protected]
P.S. A note on Fred's timings.
-------------------------
I stated above that there was a fixed overhead associated with drawing a
graph
and that this overhead did not depend on dataset size. That is not entirely
true, but it will be in the next ado-update (available sometime tomorrow,
Friday).
Fred's timings showed an unexpectedly large difference in speed going from
Stata 7 to Stata 8 and this difference could only be explained by something
dependent on dataset size. Such large differences will occur only under
Stata/SE and using datasets with many observations and, surprise!, can be
fixed by an ado-file (rather than executable) update.
<end>
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
