Paging / Streaming

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  Load up a large dataset
2.  Drag a large row and column onto the cube
3.  Good luck :)

What is the expected output? What do you see instead?
Just a personal recommendation, but you might want to try getting your 
speed comparable to MS's PivotTable.  Though old and not fancy, it is 
definitely fast for large datasets; that is the one thing I see Ranet 
really lacking in (unfortunately).

What version of the product are you using? On what operating system?
118

Please provide any additional information below.
I like your controls, but the speed for working with large data is 
lacking.  But, good luck!  It is definitely doable, and with some clever 
programming you should come out quite fine :)

Original issue reported on code.google.com by woodswal...@gmail.com on 26 Oct 2009 at 3:12

[GoogleCodeExporter]

Hi woodswalben,

Yes, we are working on this.

Warm regards,
Anatoly

Original comment by Galaktik...@gmail.com on 27 Oct 2009 at 7:59

• Changed state: Started
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by Galaktik...@gmail.com on 23 Dec 2009 at 10:55

• Changed state: FixCommited

[GoogleCodeExporter]

See latest-unstabilized repository.

Generating and transferring data from server to client took the most time.
JSon and ZIP using cuts down network traffic more than 10 times for large 
queries.

After this optimization OLAP server query execution time have became the most 
long.

So we decide not to implement paging/streaming for now.

If you find the situation where paging is necessary please feel free to report. 

Original comment by Galaktik...@gmail.com on 28 Dec 2009 at 6:34

[GoogleCodeExporter]

This did help, thank you.  However, most of the time for our large queries is 
actually spent presumably generating the GUI elements client-side.  The query / 
request takes 10 seconds now with one large query, but the UI does not update 
for an 
additional 20 seconds.  Streaming would greatly cut down this initial load time.

Original comment by woodswal...@gmail.com on 4 Jan 2010 at 8:57

[GoogleCodeExporter]

Original comment by Galaktik...@gmail.com on 5 Jan 2010 at 6:21

• Changed state: Accepted

[GoogleCodeExporter]

As a clarification, it might be worth trying to stream the generation of GUI
components on demand, as opposed to streaming the whole query.

Original comment by woodswal...@gmail.com on 5 Jan 2010 at 3:44

[GoogleCodeExporter]

Thanks, it is quite possible that you are right.
But streaming is rather drastic approach.
It vastly changes all behaviour and capabilities of the control.
For example if we have not downloaded full query result we cannot make any 
client
sorting.

At first we need to profile the control to find bottlenecks.
I think there are several ones now.

Streaming cannot solve all performance issues,
particularly besides cells GUI components creating there are many parts of work:
- axis-es download and building (do we need streaming there?)
- cell properties allocation (remove duplications)
- cache building (can be optimized)
- etc...

If we will find that the only way to optimize respond time is streaming we of 
course
do it.

Warm regards,
Anatoly

Original comment by Galaktik...@gmail.com on 5 Jan 2010 at 4:40

[GoogleCodeExporter]

Well, as I mentioned in comment 6, a good place to start would be to not 
initialize 
all rows as GUI elements, but generate them as the view is scrolled.  It would 
probably be worth seeing how much that speeds things up.  Plus, this way you 
would 
have the whole query information, but the heavy-duty client-side work would be 
mitigated.

Original comment by woodswal...@gmail.com on 6 Jan 2010 at 4:07

[GoogleCodeExporter]

Original comment by Galaktik...@gmail.com on 15 Jan 2010 at 8:42

• Changed state: Delayed

[GoogleCodeExporter]

Original comment by Galaktik...@gmail.com on 25 Feb 2010 at 5:53

• Added labels: Priority-Low
• Removed labels: Priority-Medium