|
PureBytes Links
Trading Reference Links
|
>same thing doesn't make intuitive sense. The assumption here is that all
>programs written in 32 bit code are going to be faster than 16 bit code. I
>haven't done any work with this type of conversion so I couldn't say for
>sure if this is a valid assumption.
I have converted an app that was over 200,000 lines of code from 16- to
32-bits and on a 32-bit OS, it was up to 4 times faster in some areas
involving memory allocation and disk access.
>Still, you would think that even the
>worst conversion from 16 to 32 bits shouldn't make the program slower by
>200%.
Excellent point. No one would expect this. I would join the call to TS4
32. Hopefully Osmegma wouldn't screw that up.
>So what else could be slowing it down? Another reason could be that TS
is
>relying on code written in a different language. VB perhaps? No way! Yes.
Possible in some cases, but I doubt they are using VB for the backend data
stuff. Of course it's Osmegma so who knows.
>What's another reason? Perhaps there's just more data to load in TS5 than
>in TS4. Omega probably uses a different mechanism for not only storing but
>retrieving data than in TS4. TS5 records seconds, TS4 doesn't. TS5 offers
This is highly likely. Programmers (bad programmers) tend to rely on
gee-whiz optimizations for performance enhancements rather than thinking
thru new algorithms. Compiler optimizations (not including those of complex
numerical apps written in Fortran) usually improve an application's
performance by only a few percentage points. Different algorithms can
provide orders of magnitude improvements in performance. Algorithms require
thinking, sometimes more code (sometimes less), and always objective
performance analysis. Compiler optimizations these days require clicking a
checkbox.
>It seems TS5 makes heavy use of ODBC while
>TS4 uses something else (BTRIEVE file?). The process of loading in that
>extra data and using ODBC could add a lot of overhead to the TS5
>optimization runs that TS4 doesn't have to deal with.
This is probably the main factor in the performance problems. A few years
ago I wrote an app that accessed about 60 different data files. We had had
to change file storage systems in the past so I wrote this app to allow very
easy switching of the storage format. When I was done I timed the software
running against the same data set stored in an Access database going thru
ODBC and stored in a Paradox format going thru a binary interface to
Borland's Data Engine (similar in nature to Btrieve). The result:
Paradox/BDE was 8 times faster (and in some cases 12 times faster) than
Access/ODBC. I think the real problem was/is ODBC. It is very large, very
slow and goes thru numerous layers of software to get it's job done. I
would expect a similar yawning chasm of performance between TS5/ODBC and
TS4/Btreive. Btreive has been around since the early '80's and is well
optimized. Even though I made the huge performance difference well known to
all involved with the project, all of the other programmers on the project
still wanted to use ODBC because it was new and cool. It was the "in
thing". Apparently it still is and there are still programmers who would
rather be cool than write high performance software. Laziness plays a part
here too. Most EL programmers could write SQL Select statements (used by
ODBC), but accessing data thru a binary interface in C/C++ is a little more
work. Fast coding does not equal fast execution.
>TS5 is all COM based
>and we don't know how the modules are communicating or how they're
threaded.
>Perhaps the decrease in performance has to do with making TS5 COM
>compatible. Maybe Omega will get around to optimizing this part of TS
later
>but for now, they've got other bugs to fix.
They can't optimize COM. Sadly, neither can Microsoft. The Registry is the
foundation upon which Microsoft has built NT and 95/98. I believe it will
be one of the things that brings Microsoft down.
>TS5 is more Microsoft compliant
>than any other app they've written but that doesn't mean it should run
>better.
read "MS compliance = slow". Bummer.
>The point here is that there's a reason why TS5 is slower and it's not nec
>because it was poorly implemented in the code. Some of the reasons may be
>outside the control of Omega.
Poorly implemented code doesn't help. And they had a choice on whether to
use ODBC or not.
>TS5 is a big program that attempts to be
>everything to everybody (aka Win2K).
Funny you should mention that, Microsoft recently announced they are
building a "Data Engine" into the operating system starting with W2K.
Expect similarly poor performance from future applications.
>Take heart though. As machines become faster and faster in the
>not-so-distant future, the performance inadequacies of TS5 will fade away.
>In the meantime, there's TS4.
Will Osmegma pay for my hardware upgrade?
And do not mistake me for a Microsoft basher, since 1987 I have made a
living writing applications for solely Microsoft operating systems using
mostly Microsoft tools. And I feel that the DoJ lawsuit is misguided. Not
completely wrong, but misguided.
Kent
|