Does anyone know how the processing speeds of the various Pick and
Pick-like systems stack up?

For example, we run mvBASE, which I would characterize as very fast --
sorting a 100,000 record file takes less than four seconds and is
almost instantaneous if the frames are already in memory.

I hear some of the others (jBase, Universe, etc.) are considerably
slower. Is this true, and if so, how much slower?

David Ousele
deva at oregoncoast dot com

We've seen a few benchmark discussions here over the years. It may be
good to check Google Groups for the history. It would be interesting
to see older benchmarks run on newer releases though.

Tony

deva (AT) oregoncoast (DOT) com (David Ousele) wrote:

On 17 Oct 2003 13:20:41 -0700, deva (AT) oregoncoast (DOT) com (David Ousele)
wrote:

I don't have a lot of benchmarks, but some obervations.

The first is, that for most users on modern hardware, all of the
variants are "fast enough". This is a pretty blanket statement, but
with 2G+ cpus and >1G of RAM, it is just not that hard supporting 50
users anymore.

I will try to break some thinks down by platform:

Windows:

Run-time basic performance.

1. D3 w/ flash
2. jBase
3. mvBase
4. Universe
5. D3 w/o flash
6. Unidata

IO performance reading

1. mvBase
2. D3
3. jbase/Universe/Unidata ( I have only vaguely tested these
for this)

IO performance writing

1. mvBase
2. jbase/Universe/Unidata ( again only vague testing )
3. D3 w/ update protect on

Linux is about the same except:

mvBase does not exist.
D3 with update protect on is an even bigger hit on writes.

D3/mvBase seems to have the smallest memory footprint per user (not
that this matters much).

Linux is more robust, mostly because errant processes are easier to
nuke without taking the entire DB down.

jbase/U2 on Windows has "some" of the robustness of Linux in terms of
nuking individual processes.

D3 update protection is a real chunk of overhead, particularily if you
have undersized files.

mvBase is 100% susceptible to crashes. If you crash mvBase on a busy
system with lots of updates, you can end up with spaghetti and
hundreds or thousands of GFEs. This is "traditional" R83 Pick
behaviour.

My experience is best comparing BASIC run-time performance. Our web
server really hits this part of the system hard and this is the order
that they platforms finish in.

jbase has some theoretical limitation because of the way it manages
code. It can be impractical to build "really large" application that
have 10,000+ subroutines because of the DLL/shared-lib footprint.
Other platforms all use p-code (even Flash) so this is less of an
issue and management of object code is much more granular.


--------------------------------------------------------------------
Doug Dumitru 800-470-2756 (610-237-2000)
EasyCo LLC doug (AT) easyco (DOT) com http://easyco.com
--------------------------------------------------------------------
D3, U2, jBase Virtual Servers. Off-site backup over the internet.
Develop/test/deploy from $20/mo. Fast, secure, cheaper than tape.
http://mirroredservers.com http://mirroredbackup.com

Lots of good information from Doug below.

2-3 years ago the MaVerick project did some benchmarking for INSERTs,
EXTRACTs and DELETEs. Below is the program used and the output
from my laptop. Now one interesting occurance was that the last line of
the test showed that mvBASE couldn't handle the full test (the sum never
came out right, versions tested: 1.0, 1.1 & 1.3).

The code:
PRINT "COUNT"'R#15':"INSERT"'R#15':"EXTRACT"'R#15':"SUM" 'R#15'
FOR X = 1 TO 5
DA=''
LIMIT = 10^X
START=SYSTEM(12)
FOR Y = 1 TO LIMIT
DA = INSERT(DA, 1,0,0, Y)
NEXT Y
MIDDLE=SYSTEM(12)
TOT = 0
FOR Y = 1 TO LIMIT
TOT += DA<Y>
NEXT Y
FINISH=SYSTEM(12)
PRINT LIMIT'R#15'MIDDLE - START)'R#15'FINISH -
MIDDLE)'R#15':TOT'R#15'
NEXT X


The results when run from my laptop (Athlon mobility 1500+, 512MB RAM, jBASE
3.4.4):
jsh bcoleman ~\3e -->BENCHMARK
COUNT INSERT EXTRACT SUM
10 0 0 55
100 0 0 5050
1000 0 0 500500
10000 312 16 50005000
100000 109703 125 5000050000
jsh bcoleman ~\3e -->

-Bob

"Doug Dumitru" <doug (AT) easyco (DOT) com> wrote

"Bob" wrote > mvBASE can't handle this test <snipped>
No mvBASE here, but I'm guessing it fails this simpler test too;

you'll
ever use in a FOR loop upper limit -- it may just stop early without an
error message.
Also, I could suspect 10^X might not be an exact integer for large enough
X...

Thanks, Doug! I appreciate the comprehensive breakdown.

Right now, my main interest is IO speed, and I see you have mvBASE
ranked #1. How much faster is it than jbase/Universe/Unidata? A
little bit? Twice as fast?

David Ousele
deva at oregoncoast dot com

Without quantified benchmarks, I have tested my own forms processor on the
speed it takes to manage a page (80x24) of report information. The program
is string intensive (lots of inline string replacement using braketted
string extract statements and concatenated rebuild statements). Here is
what I have found (in order of fastest to slowest)

Agan - these timing are not exact- just am ad-hoc timing.

Universe - less than 1/2 second
jBase - less than 1.2 second
mvBase - about a second
d3 (one page - not flashed- takes 9 seconds)

This is dramtic difference- especially since the code is identical on each
platform

Harv

"David Ousele" <deva (AT) oregoncoast (DOT) com> wrote

"Frank Winans" <fwinans (AT) airmail (DOT) net> wrote

<SNIP>
This is so true! I had no say in the mvBASE system as I was the warehouse
manager at the time. I played with jBASE for 4 years before committing to
the switch. Raining Data helped by buying out GA'a database products.

-Bob

Don't suppose you would like to flash-compile under D3 & publish the
results on the same test ?!?!, otherwise as an (assumed) 30 fold
performance boost for string handling, I'm assuming the time would be
around .3 seconds - but I'd be interested in seeing a REAL figure

(I'm also assuming these benchmarks were run on the same machine)


"SixFtWabbit" <dragoninbabylon (AT) cox (DOT) net> wrote

The UV and D3 "tests" were done on identical 500MHz machines with 256K of
RAM.. both under Linux 7.1. I also tested D3 on an identical NT box.
mvBase was a 300 MHz NT machine. jBase was a 900Mhz NT machine.. But I got
similar results from a 500Mhz machine. Both machine had 256K of RAM
(since this was not a scientific comparison, the timings differences were
negligible).

On the subject of mvBase.. It is fast, but has many of the limitations of
it's Mentor ancestor in terms of object code sand descriptor table size. As
Ian Sandler once said, "mvBase is blindingly fast and feature-free."

"Ross Ferris" <ross (AT) stamina (DOT) com.au> wrote