Data item expressions from a library [message #482233] |
Tue, 25 August 2009 19:05 |
James Koch Messages: 23 Registered: July 2009 |
Junior Member |
|
|
We're trying to use a library to define a Data element which we use across
multiple reports. The element's expression is a non-trivial formula.
Functionally, this is working, however this approach is killing
performance (in 2.3.2.1 at least). We're seeing report generation time go
from 12s to 5 minutes, and the rptdocument go from 18MB to 146MB, although
the outputs seem to match.
I know there are some caching enhancements in 2.5, but we're stuck w/ 2.3
for now, so I'd love to hear ideas for a work-around, if any exist other
than copy/pasting our expression into local Data elements on each report.
I can also reproduce this w/o a library. Essentially the acceptable
performance occurs when the Data element references a binding on the
table, and the poor performance occurs when the Data element has its own
bindings (which is how it would come from a library).
Thanks,
James
|
|
|
|
Re: Data item expressions from a library [message #482424 is a reply to message #482234] |
Wed, 26 August 2009 13:48 |
|
James,
Have you tried using a text element with the value-of expression in a
library? It would be good if you could reproduce the problem using the
sample db so we can see what is causing the issue.
Jason
James Koch wrote:
> Clarification of first paragraph - I'm comparing the same report, except
> that one uses a library-defined Data element while on the other I've
> manually added the Data element and set it's expression.
>
|
|
|
|
Re: Data item expressions from a library [message #482518 is a reply to message #482454] |
Wed, 26 August 2009 21:14 |
|
James,
Can you post the library you used?
BTW I did not see a reference to a library in the example report.
Jason
James Koch wrote:
> We'll give the text element a try.
>
> To reproduce w/ the sample DB, here are two rptdesign files:
>
> http://jameskoch.googlepages.com/GroupingLabelPerf-Library.r ptdesign
>
> http://jameskoch.googlepages.com/GroupingLabelPerf-Local.rpt design
>
> The "local" one just has the data item added the way the designer does
> it (a new table binding is created, and referenced by the data item).
>
> The "library" one is how it appears when we drag a library-defined data
> element over (it has its own bindings).
>
> There's no noticeable performance issue here but the size difference in
> the rptdocument is observable - "local" is 2,375K and "library" is 4,498
> for the same output. I suspect multiple round-trips to the data source
> are happening under "library", causing a dramatic slow down in cases
> like ours where a beefier PROC is running each time.
>
|
|
|
|
Re: Data item expressions from a library [message #482720 is a reply to message #482691] |
Thu, 27 August 2009 16:49 |
|
Ok now I understand. The group data element contains a data binding
which is nested in the table binding, which is most likely why it is
growing. It is probably parsing the data set twice because of the
nested binding. I changed your report to use a text element and the
size went back to the original size.
Jason
SuperTime wrote:
> Jason,
>
> In the http://jameskoch.googlepages.com/Gro...rary.rptdesign, James has
> mimicked the binding of the data element "From Library" just like as if
> it was added from the library.
>
> Hope this helps.
>
>
|
|
|
|
Re: Chart and Table aligned [message #482932 is a reply to message #482891] |
Fri, 28 August 2009 15:10 |
|
Tero,
Can you post an example? In 2.5 you can set label spans in the chart to
help align two charts. This may help with your situation.
Jason
Tero wrote:
> Hello,
>
> Is it possible to have a chart (let's say a bar-chart) and just below of
> it a table with the values.
> I can do that manually, but is not a clean (not to mention elegant) way:
> I have to play with the sizes (chart/table) until it somehow fits: the
> borders of the columns of the table (nearly) match the X-Axis gridlines.
>
> I would be also happy with a better workaround if not a straight-fwd
> solution :)
>
> Thanks!
> Tero
>
|
|
|
Re: Data item expressions from a library [message #485426 is a reply to message #482720] |
Fri, 11 September 2009 17:16 |
James Koch Messages: 23 Registered: July 2009 |
Junior Member |
|
|
Wow, a thread-jacking!
I've made an interesting related finding here. Even w/ non-library data items in our header (IOW, there's no duplicate data-item-level binding, which was our original issue), we get a 45% performance boost when we switch to text elements.
Some facts & wild theories:
- We have a 10-20 line expression needed for our header/footer labels.
- When you add them as a DataItem you get an associated Table Binding.
- I'm guessing that this means the expression is evaluated on every row, rather than just on the change of groups.
- We have a large # of rows, so there's a huge cost to compute the expression w/ every row, so switching to a text element gives us a giant boost by (presumably) evaluating only on change of group.
[Updated on: Fri, 11 September 2009 17:17] Report message to a moderator
|
|
|
Re: Data item expressions from a library [message #485431 is a reply to message #485426] |
Fri, 11 September 2009 17:30 |
|
James,
Is this page or table headers?
Jason
James Koch wrote:
> Wow, a thread-jacking!
>
> I've made an interesting related finding here. Even w/ non-library data
> items in our header (IOW, there's no duplicate data-item-level binding,
> which was our original issue), we get a 45% performance boost when we
> switch to text elements.
>
> Some facts & wild theories:
> - We have a 10-20 line expression needed for our header/footer labels.
> - When you add them as a DataItem you get an associated Table Binding.
> - I'm guessing that this means the expression is evaluated on every row,
> rather than just on the change of groups. - We have a large # of rows,
> so there's a huge cost to compute the expression w/ every row, so
> switching to a text element gives us a giant boost.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.13689 seconds