SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Applix is back in action -- Ignore unavailable to you. Want to Upgrade?


To: Warren Whitney who wrote (2088)1/8/1998 3:43:00 PM
From: Kashish King  Read Replies (1) | Respond to of 3014
 
The comments regarding execution on the client was interesting: you can't run code on a terminal and only company moving toward terminal-based systems is Microsoft. Who cares what the performance is using 1970's architectures, or modern-day Microsoft technology, as it were? Hopefully the fundamental difference between thin-client-, fat-client- and terminal-based computing becomes manifest in 1998; that's certainly not the case now.



To: Warren Whitney who wrote (2088)1/9/1998 8:29:00 AM
From: Dr. J  Read Replies (1) | Respond to of 3014
 
As I had hypothesized, Applix's overall figures were just behind Oracle. Also note comments re validity of Applix's methodology (although it sems to me this is actually in Applix's favor: if a low-power client can give good results, then the product is pretty fast)

Now, Applix has published figures for TM1 Server 6.0, running the same benchmark but on much cheaper hardware than Oracle or Arbor. The TM1 overall AQT figures are just behind Oracle's, but Applix has proved its claims that TM1 can start answering queries much quicker after a data update -- it was in action after just 13 minutes, whereas Express took 83 minutes and Essbase took a mammoth 304 minutes. Express was much quicker than the other products at servicing queries, TM1 came a good second, and Essbase came last again. Express only overtook TM1 after the latter had dealt with some 170,000 queries, and Essbase was much slower than both. The TM1 database was actually smaller than the input data, whereas Express and Essbase showed varying amounts of database explosion. Even though they were both storing exactly the same quantity of input data, the Essbase database was more than 300 times larger than TM1's. Also, unlike the others, TM1 required no server procedures or calc scripts to force calculations to occur.

As with the previous Oracle Express benchmark, Arbor has vigorously attacked Applix' implementation of the benchmark, which contravenes some of the OLAP Council's rules, despite being audited by the NSTL. In particular, some parts of the benchmark were executed on the client, as they would be in a real-world application, but the benchmark rules do not permit this. While these errors were probably accidental, and may not have had a significant effect on the timings, it does raise question marks about the usefulness of the results