If I have an array lets say with 15000 rows and set the edit table to display it will take forever. Is there a better way of doing this?

I believe many years ago I remember writing paging routines to show so many at a time, but I was hoping that wasnt necessary now.

Thx all!

d

Daniel

If I load an array with 15000 rows of 4 columns it display immediately. Are you sure the problem is not in the logic of building the array.

There was a mod to one of the more recent releases which made loading edit tables several hundred times faster. Are you using an older release?

The Sprezzatura Group

World leaders in all things RevSoft

Thanks all for you replies.

This is with 7.21. Perhaps I do need to double check where the slowdown is happening.

d

if you are using then that will cause real slowdowns

] if you are using then that will cause real slowdowns

What would you suggest?

thx

d

Daniel,

As Dave mentioned the problem with the "" operators is that they always start from the beginning or a string to calculate the position to operate on, so over many iterations of a large string you could get a noticable performance hit.

They do make code more easily maintainable however - it's that old tradeoff of code maintainability vs performance. An increase in one tends to lead to a decrease in the other :(

If you can it's better to simply concatenate the items you need for an array …

so instead of this:

pre.code {

 background-color: #E5E5E5;

 border: 1px solid #000000;

 width: 640px;

 padding: 5px;

 font-family: courier, verdana, arial, serif;

 margin: 0px 10px auto;

}

  array="
   for x=1 to 10000
      array=SomeData
      array=SomeMoreData
   next

you could do this:

   array="
   for x=1 to 10000
      array := SomeData : @vm : SomeMoreData : @fm
   next
   array-1,1="

If you want to try some timings use the dosTime() function to compare the start and end times of the operations.

The Sprezzatura Group

World leaders in all things RevSoft

Daniel,

As Dave mentioned the problem with the "" operators is that they always start from the beginning or a string to calculate the position to operate on, so over many iterations of a large string you could get a noticable performance hit.

They do make code more easily maintainable however - it's that old tradeoff of code maintainability vs performance. An increase in one tends to lead to a decrease in the other :(

If you can it's better to simply concatenate the items you need for an array …

so instead of this:

pre.code {

 background-color: #E5E5E5;

 border: 1px solid #000000;

 width: 640px;

 padding: 5px;

 font-family: courier, verdana, arial, serif;

 margin: 0px 10px auto;

}

  array="
   for x=1 to 10000
      array<x,1>=SomeData
      array<x,2>=SomeMoreData
   next

you could do this:

   array="
   for x=1 to 10000
      array := SomeData : @vm : SomeMoreData : @fm
   next
   array-1,1="

If you want to try some timings use the dosTime() function to compare the start and end times of the operations.

The Sprezzatura Group

World leaders in all things RevSoft

Note to self… Remember to escape in code snippets

yep .. as Sprezzatura says .. concat your data is always faster when you are building large strings.

so we always find that if building large tables with more than a couple colums we build each column

col1 := @vm : data

col2 := @vm : data2

col3 := @vm : data3

col4 := @vm : data4

col5 := @vm : data5

col6 := @vm : data6

in your loop then at the end

array=col1:@fm:col2:@fm:……

and stuff the array property

If there is still a lot of time being taken .. what .. trying to load 100K rows of 10 colums so the user can wander through???

In a case like this it would be best to have your loop do x number of rows (x depending on the amount of time you can wait) then stuff the control then a yield allowing the user to do something then continue building the control data. this would be similar to what they do for popup ..

hope this helps

Also the REMOVE statement can be faster then the extract (x=y) statement on large dynamic arrays. However caution must be used since the REMOVE statement teases apart a spectrum delimited levels (FM, VM, SVM etc). Didn't Mike say at the last users conference though that some of these speed difference were not a pronounced in OI32 then the are in ARev and OI16? </QUOTE> —- === At 26 JUL 2006 02:23PM Warren Auyong wrote: === <QUOTE>"As Dave mentioned the problem with the "" operators is that they always start from the beginning or a string to calculate the position to operate on, so over many iterations of a large string you could get a noticable performance hit." Prime Information at one point changed how the position pointer worked on the EXTRACT/INSERT/REPLACE/"" statement, so that it would remain at the last accessed position rather than resetting to the start each time. I don't know if this change is still in effect in UniVerse or why other MultiValue implementations have not adopted this behavior. As you can imagine this led to the anticipated speed boost in most cases. </QUOTE> —- === At 26 JUL 2006 03:22PM The Sprezzatura Group wrote: === <QUOTE>Warren, Way back in the days of jRev (before it was LiveWater) Cam had a java DynArray class that cached positions. I was told it improved performance but I never got to test it alas… The Sprezzatura Group World leaders in all things RevSoft </QUOTE> —- === At 26 JUL 2006 05:06PM Warren Auyong wrote: === <QUOTE>Odd, I moved over to the Rev/ARev side rather exclusively about the time Prime made the changes. So I never had any hands on experience of the change either. What ever happened to LiveWater? (Do we even want to go there? ) </QUOTE> —- === At 26 JUL 2006 06:49PM Richard Hunt wrote: === <QUOTE>Given that the REMOVE statement in Prime and UniVerse is as follows… REMOVE AMOUNT FROM AMOUNTS SETTING MORE and the same statement in Arev and OI is… REMOVE AMOUNT FROM AMOUNTS AT POS SETTING MORE Notice the "POS" variable in Arev and OI. I would think that might be an indicator that Arev and OI do not have internal pointers for dynamic arrays like Prime and UniVerse had/has. Just thought I would offer this. </QUOTE> —- === At 27 JUL 2006 12:23AM Daniel Sternklar wrote: === <QUOTE>I could also use matrix arrays and then do matparse/matunparse as well. Isnt that supposed to be faster as well? d </QUOTE> —- === At 27 JUL 2006 09:25AM [email protected] wrote: === <QUOTE>it is .. but to me it isn't really called for in this instance. Here you are wanting to build a big string which has x fields (columns in the edittable) and n values (rows in the edit table). so simply create X vars and concat the N values to the vars. then simply concat the vars together (in the right order ) and stuff the table. But you bring up a really good questions .. maybe what would be good is for you to build a test routine which creates 2 'table arrays' as you would want to stuff the edit table. 1 using the matparse/unparse feature and one simply concating the data. Then report back which is the fastest. It would be insteresting to know .. though being a simple guy like i am .. i would probably stay with the concat as there are less bits (or so it seems to me) Let us know .. dsig </QUOTE> View this thread on the Works forum...