In message
ba2f7087c5e55f4cb14ec12d9bee354501a20...@svr-email-1.civica.root.local,
Edward Brown ebr...@civica.co.uk writes
After indexing, we made a lot more use of the SETINDEX and READFWD
logic
in our programs.
I find this curious / disappointing - is it really the case that unidata
can't
] On Behalf Of Ron Hutchings
Sent: 09 July 2009 13:40
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] General guidelines on indexing
IBM BOX (OLDER)
PICK.FORMAT
10.0.11
6.9377 seconds
Linux box
PICK.FORMAT
10.2.0
0.3522 seconds
Date: Thu, 9 Jul 2009 11:20:25 +0800
From: adrian.wom
both code and their os and u2 configuration !
-Original Message-
From: Symeon Breen [mailto:syme...@gmail.com] Sent: 09 July 2009 14:04
To: 'U2 Users List'
Subject: RE: [U2] General guidelines on indexing
Unidata 7.1 (32bit) on redhat EL 3 64bit, on XEON E5335 with 4 gig
ram. \
Error
and their os and u2 configuration !
-Original Message-
From: Symeon Breen [mailto:syme...@gmail.com]
Sent: 09 July 2009 14:04
To: 'U2 Users List'
Subject: RE: [U2] General guidelines on indexing
Unidata 7.1 (32bit) on redhat EL 3 64bit, on XEON E5335 with 4 gig ram.
Error when creating
configuration !
-Original Message-
From: Symeon Breen [mailto:syme...@gmail.com]
Sent: 09 July 2009 14:04
To: 'U2 Users List'
Subject: RE: [U2] General guidelines on indexing
Unidata 7.1 (32bit) on redhat EL 3 64bit, on XEON E5335 with 4 gig ram.
Error when creating a shared memory segment
...@listserver.u2ug.org] On Behalf Of Mecki
Foerthmann
Sent: Friday, July 10, 2009 7:31 AM
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
Well, if it makes you feel better, my test crashed out with a similar
error message as well.
The size shown was about half of what you had, otherwise
this can be of benefit to people to fine
tune both code and their os and u2 configuration !
-Original Message-
From: Symeon Breen [mailto:syme...@gmail.com] Sent: 09 July 2009 14:04
To: 'U2 Users List'
Subject: RE: [U2] General guidelines on indexing
Unidata 7.1 (32bit) on redhat EL 3 64bit
4:15 AM
To: 'U2 Users List'
Subject: Re: [U2] General guidelines on indexing
Ok I am very jealous now of all these quick times, when my one crashed out
Can someone remind me (its been years since i did any udt config stuff) what
should i be looking at to fix this error
Thanks
PS - i like
Hi Adrian,
I just tried this example on Universe 10.2.6 - it took 0.0665
seconds basically instant, can't complain about that.
I am sure that something must have been wrong with your test. This probably
isn't long enough to do even the empty loop with no string copy.
I have just repeated
...@listserver.u2ug.org] On Behalf Of Martin
Phillips
Sent: Thursday, 9 July 2009 4:39 PM
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
Hi Adrian,
I just tried this example on Universe 10.2.6 - it took 0.0665 seconds
basically instant, can't complain about that.
I am sure
2009 15:30
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
Maybe one of you would be willing to pull all these good
posts on indexing into a wiki article? It would be handy
reference material and could save someone from hours of
pain can't get this stuff from
IBM BOX (OLDER)
PICK.FORMAT
10.0.11
6.9377 seconds
Linux box
PICK.FORMAT
10.2.0
0.3522 seconds
Date: Thu, 9 Jul 2009 11:20:25 +0800
From: adrian.wom...@rac.com.au
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] General guidelines on indexing
I just tried this example on Universe
Hutchings
Sent: 09 July 2009 13:40
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] General guidelines on indexing
IBM BOX (OLDER)
PICK.FORMAT
10.0.11
6.9377 seconds
Linux box
PICK.FORMAT
10.2.0
0.3522 seconds
Date: Thu, 9 Jul 2009 11:20:25 +0800
From: adrian.wom...@rac.com.au
To: u2-users
: [U2] General guidelines on indexing
I just tried this example on Universe 10.2.6 - it took 0.0665 seconds -
basically instant, can't complain about that.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin
Thanks for cleaning up my mess, Brian. You won't have to do it again, at
least not because of me. :-)
In the meantime, I've copied those new sections on indexing into the new
wiki and kept the attribution.
Brad Schrag
Application Consultant
Commercial Leasing Development
U.S. Bank
EP-MN-BGF
Hi all,
I wish I hadn't started this!!
I did my tests on Windows. It looks like I need to try other platforms when
time permits.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200
14:56
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
I did my tests on Windows. It looks like I need to try other
platforms when time permits.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200
Original test and a couple of other variations. We use the DIM approach in
several cases where variable data is large and temporary.
Test system run on
WindowsXP
Single DuoCore @2.20ghz
2GB Ram
Original version - -1 variable append
Elapsed Time 00:25:04
Altered version - Using WRITESEQ - Same
!
- Original Message
From: David Ward damad...@comcast.net
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Thursday, 9 July, 2009 16:24:17
Subject: Re: [U2] General guidelines on indexing
Original test and a couple of other variations. We use the DIM approach in
several cases where
-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Marco
Manyevere
Sent: 09 July 2009 16:28
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
On my DualCore WindowsXP laptop with 3GB ram @2.16GHZ, (UV 10.0.04):
The dynamic
] General guidelines on indexing
Original test and a couple of other variations. We use the DIM approach
in
several cases where variable data is large and temporary.
Test system run on
WindowsXP
Single DuoCore @2.20ghz
2GB Ram
Original version - -1 variable append
Elapsed Time 00:25:04
Altered
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
We used to us the DIM approach as well. But having the process blow up a
couple of years later because the DIM array was not large enough to
accommodate the data caused us to go the work file method. The DIM array was
fast
Hi Marco,
The dynamic array test took 30 minutes.
I compiled the same program on jBASE 4.1 on the same laptop
and it completed in 0 seconds!
This will be because jBase effectively converts the program to C. Most C
compilers are so good at optimisation that they will work out what the
Sent: Thursday, 9 July 2009 12:59 AM
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
By way of a simple expample, I just tried the following program...
s = ''
z = str('*', 1000)
t1 = time()
for i = 1 to 10
s-1 = z
next i
t2 = time()
crt t2 - t1
: Re: [U2] General guidelines on indexing
UD v7.2 on Dell 1435 server w/2GB RAM and 180 SATA RAID 1 drive.
s = ''
z = STR('*', 1000)
t1 = SYSTEM(12)
FOR i = 1 TO 10
s-1 = z
NEXT i
t2 = SYSTEM(12)
CRT t2 - t1 : milliseconds.
- RUN BP TEST
1625 milliseconds
Bill
Steve
...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Joshua Gallant
Sent: Thursday, July 09, 2009 12:58 PM
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
0.1239 seconds running on a Solaris machine with UV 10.2.2 and 250 other
users.
- Josh
Dell Poweredge 2900, 4 core, 2 cpu Xeon - 16gb ram, UDT 6.1 - Windows
2003 R2
s = ''
z = STR('*', 1000)
t1 = SYSTEM(12)
FOR i = 1 TO 10
s-1 = z
NEXT i
t2 = SYSTEM(12)
CRT t2 - t1
Output: 1219
___
U2-Users mailing
I tried it on my system UV 10.1.12 on Linux AS3 0.643 seconds.
--
From: Martin Phillips martinphill...@ladybridge.com
Sent: Thursday, July 09, 2009 3:38 AM
To: U2 Users List u2-users@listserver.u2ug.org
Subject: Re: [U2] General guidelines
We've recently implemented indexing into our application as a
replacement for our own custom indexes, so I'm at least a little bit
qualified to answer some of your questions:
* Number of indexes - no guidelines afaik. The update process seems fast
enough - certainly, every write triggers an
Be careful not to index on a foreign key, i.e. do not index a field that
is a tlookup or trans to another file.
An example is if custno is on the order header,and you xlate it to
order.line, do not index order.line by custno. It will not update
properly.
U2 indexing is such a breath of
] On Behalf Of Edward Brown
Sent: Wednesday, July 08, 2009 6:12 AM
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
After indexing, we made a lot more use of the SETINDEX and READFWD
logic
in our programs.
I find this curious / disappointing - is it really the case that unidata
: [U2] General guidelines on indexing
When you have a file with 50 million records, it does not matter how
you build the or parse the dynamic array. A well sized work file will
run circles around the dynamic array.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
Edward Brown wrote:
I don't agree. Disk access is inherently slower than RAM access.
Therefore a process that makes efficient use of RAM will be faster than
an equivalent algorithm making efficient use of disk.
In your case, it's just a matter of scale:
50 million records at (lets say) 14
Just a quick note on indexes... and kind of goes to the EMC question.
The location of the index is stored in header of the file itself! This can
lead to a problem if you have a copy of the data somewhere else
and try to use it. For example, we'll occasionally want to see how a
file/record
Maybe one of you would be willing to pull all these good posts on indexing into
a wiki article? It would be handy reference material and could save someone
from hours of pain can't get this stuff from reading the system docs.
http://212.241.202.162/U2UGWiki/moin.cgi/ForDevelopers
-Baker
are generated from
the same work file.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Edward Brown
Sent: Wednesday, July 08, 2009 6:47 AM
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
I don't agree. Disk
Robert Porter wrote:
Just a quick note on indexes... and kind of goes to the EMC question.
The location of the index is stored in header of the file itself! This can lead to a problem if you have a copy of the data somewhere else
and try to use it. For example, we'll occasionally want to see
: Baakkonen, Rodney A (Rod) 46K rodney.baakko...@cigna.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Wednesday, 8 July, 2009 17:15:57
Subject: Re: [U2] General guidelines on indexing
In theory, I would have to agree with you. Who knows how all this stuff
really works under the hood. You have
Sorry yes, I was speaking of UV. There the data for the index is stored in
I_(filename) by default.
But inside the header of the actual file, there is a pointer to where the
indexes live.
So the indexes could live somewhere else by using the SET.INDEX command, if you
wanted to
move them for
Marco Manyevere wrote:
In one test I did a couple of months back, I found that appending IDs
to the end of a dynamic array perfomed _much_ _much_ slower than a
WRITESEQ to the end of a disk file and the dynamic array wasnt even a
100 000 records long. We were able to reduce the time required to
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
In one test I did a couple of months back, I found that appending IDs to the
end of a dynamic array perfomed _much_ _much_ slower than a WRITESEQ to the
end of a disk file and the dynamic array wasnt even a 100 000 records long.
We were
Excellent idea, Baker. I'll work on that after this thread settles down. I
won't include the dynamic array vs. work file bits since that's not
directly related to indexing.
Brad Schrag
Maybe one of you would be willing to pull all these good posts on
indexing into a wiki article? It
Hi all,
I don't agree. Disk access is inherently slower than RAM access.
I think that this discussion started for Unidata and then got UniVerse
involved too but it might have been the other way around. Sadly, there is no
internals training material for Unidata so we have to guess what goes
...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin
Phillips
Sent: 08 July 2009 17:59
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
Hi all,
I don't agree. Disk access is inherently slower than RAM access.
I think that this discussion started
I want to move to one of my earlier questions in this thread regarding
mixing indexed and non-indexed dictionary items, and if unidata is able
to use the indexed items at all in this circumstance:
Simple test:
One fairly big file:
Items - 473,000
Item size - 695 bytes on average
Indexed
All
Since we're already going off on a huge tangent re. indexing, it's worth
pointing out that if you're writing client side code in .Net the same
applies: strings are immutable and every change or append copies the string
in memory. That's why there is a StringBuilder class for appending to
Hi again Ed,
SELECT file WITH PRINT.DATE GT 01/04/2008 AND WITH ADDR LIKE 'A'0X
This query can be resolved with an index. Also, the optimiser will shuffle
the clauses to make best use of indices. Unidata had query optimisation
before UniVerse but I believe that essentially the same
Ha Ha a dev from IBM letting secrets out to ladybridge ;)
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin Phillips
Sent: 08 July 2009 20:57
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
Hi Symeon,
Ha Ha a dev from IBM letting secrets out to ladybridge ;)
Yes, it was a bit much to hope!!!
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200
___
U2-Users mailing list
I took a stab at extracting and compiling index-related info from this
thread. It's not pretty, but it's a start. Feel very free to update,
restructure or change as seems appropriate.
http://212.241.202.162/U2UGWiki/moin.cgi/ForDevelopers
Brad.
U.S. BANCORP made the following annotations
:59 AM
To: U2 Users List
Subject: Re: [U2] General guidelines on indexing
By way of a simple expample, I just tried the following program...
s = ''
z = str('*', 1000)
t1 = time()
for i = 1 to 10
s-1 = z
next i
t2 = time()
crt t2 - t1
This took six seconds on QM
Our primary application hasn't needed the performance gains offered by
indexing, but our database has grown large and complex enough that we're
looking at it seriously. Having only dabbled with indexing in test
environments, I've got a few general and best practice questions. I've
seen some
52 matches
Mail list logo
