|
View previous topic :: View next topic
|
| Author |
Message |
r arunmoezhi
New User
Joined: 26 Jun 2009
Posts: 32
Location: Chennai
|
|
|
|
I have an input file which needs to be sorted based on 4 key fields.
field A Start Pos = 31 Len=8
field B Start Pos = 39 Len=15
field C Start Pos = 54 Len=8
field D Start Pos = 62 Len=3
I have coded the sort card as below:
| Code: |
| SORT FIELDS=(31,8,CH,A,39,15,CH,A,54,8,CH,A,62,3,CH,A) |
since the sort fields are contiguous can i code the sort card as:
| Code: |
| SORT FIELDS=(31,34,CH,A) |
If yes, will there be any change in performance? |
|
| Back to top |
|
 |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| Why not try it for yourself and see what happens. |
|
| Back to top |
|
|
gcicchet
Senior Member
Joined: 28 Jul 2006
Posts: 1702
Location: Australia
|
|
|
|
Hi,
you should try it out and compare the results.
Gerry |
|
| Back to top |
|
|
gcicchet
Senior Member
Joined: 28 Jul 2006
Posts: 1702
Location: Australia
|
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
Frank or Kolusu will without doubt give the best answer
but a bit of creative speculation should not hurt anybody...
from a <general> algorithmic point of view for a monotone sort ( all ascending/descending keys )
You would need to build a full key concatenating all the subkeys
in this case defining one big key instead of 4 subkeys would save three <move> instruction
but (and we' ll never know about it ) the internal sort logic (undisclosed / patented)
might optimize the building of strings of records by using the subkey structure
but then somebody would have come along with the suggestion to arbitrarily separate in subkeys a long key
to conclude based on <common> logic the performance difference should be irrelevant and even not measurable
anyway let' s wait for the answer from the people who know better
-- still I would like to know if I am completely wrong or not 
PS.
from a theoretical point of view the complexity of a sorting algorithm could be defined as O(f(N) + N) where
f() depends on the problem complexity itself, something like N*log(N) -- usually
the other component is N ( related only to the number of records )
in the above case, building the full key, and usually the N part is ... ignored |
|
| Back to top |
|
|
r arunmoezhi
New User
Joined: 26 Jun 2009
Posts: 32
Location: Chennai
|
|
|
|
THanks for the directions. got a clear explanation given by frank:
| Quote: |
I wouldn't expect it to make any difference for DFSORT as we combine contiguous fields internally when possible as in this case. |
|
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
| Quote: |
I have coded the sort card as below:
SORT FIELDS=(31,8,CH,A,39,15,CH,A,54,8,CH,A,62,3,CH,A)
since the sort fields are contiguous can i code the sort card as:
SORT FIELDS=(31,34,CH,A)
|
Yes.
| Quote: |
| If yes, will there be any change in performance? |
Probably not. But the best way to find out is to try it yourself with your own data and judge by your own criteria for "performance". |
|
| Back to top |
|
|
|
|
