Performance issue with large number of rows

Question

Performance issue with large number of rows

okbangas

SSChampion

Points: 11773
More actions
March 2, 2012 at 4:13 am

#251870

Hi folks.
A customer of mine has requested a report which possibly can return several thousand rows. The report shall NOT be paged, as it is much faster for the end users to scroll down a large report than guessing how many pages there is, and what page they're supposed to go to. This report is now rendering just fine, and the report server is only using a few seconds to process the report. IE however, is using more than 3 minutes of CPU time to execute the JavaScript rendering the table. Does anyone know any trick, hack or whatever to improve the performance of the HTML report?

Ole Kristian Velstadbråten Bangås - Virinco - Facebook - Twitter
Concatenating Row Values in Transact-SQL[/url]

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

okbangas SSChampion Points: 11773 More actions · Answer 1

I have now digged a bit more into it, and I fear that there is nothing we can do about this, although I sincerely hope that I am wrong. It appears that the entire report is created with JavaScript, which I do find a bad idea in the first place. What's even worse, is that all sizing is overridden by JavaScripts, which is used to calculate the sizes in pixels, no matter what size you originially specified in your report. What's even worse, for every conversion to pixels, a new div is created with a width of 72pt, which is used to calculate dpi, then this div is deleted. So, for my humble table with some 3000 rows of 20 columns + paragraphs, links and so on, Reporting Services is creating a temporary div in the object model for the left, top, right and bottom padding and border of each and every element, at least once. A simple calculation: 3000*20*8 = close to half a million DIVs are created to perform half a million calculations of dpi, that I have discovered so far. Honestly, this should have been done once for the entire report.

Ole Kristian Velstadbråten Bangås - Virinco - Facebook - Twitter

Concatenating Row Values in Transact-SQL[/url]

Jeff Moden SSC Guru Points: 1003851 More actions · Answer 2

Now that you've found out what the massive overhead is, can't you just bypass it and build a report of your own?

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

okbangas SSChampion Points: 11773 More actions · Answer 3

Jeff Moden (3/2/2012)
Now that you've found out what the massive overhead is, can't you just bypass it and build a report of your own?

You mean create a web solution for this myself instead of using SSRS? Actually, it is tempting. And it would perform WAY better than SSRS. Presenting a table should not be that difficult either.