January 22, 2019 at 12:06 pm
Jeff Moden - Tuesday, January 22, 2019 11:52 AMSean Lange - Monday, January 21, 2019 2:49 PMI could easily put together a test in a VS project but it would horribly unrealistic. I can't even imagine a front end with a million rows of data. I don't care how fast your sql is, the performance to render to the UI is going to suck the life of everything including the person waiting for it. And of course the performance would vary significantly between a windows app and a web app.
The only reason why I'd do a million row test is to have enough to actually measure the outcome with. I agree that if a UI is having to address a million rows, then Murphy's half brother(Sum Ting Wong) is having a field day. It would just be to see if the front-end version would be a part of the "Death by a Thousand Cuts" and all such problematic code lends itself to.
Most front-end code is not going to apply the date formatting when the data is pulled - rather it applies the date formatting when the page is rendered. At that point - even if the .NET format code is inefficient it won't be visible to the end user (or even the developer).
We can see this in SSRS reports - which utilize the formatting code when the pages are rendered if you set the format for that column to any of the defined formats or a custom format. This formatting has a minimal effect...but then again, who is going to attempt to render a report with a million rows? If you do that - then formatting a date field in a report is not going to be your biggest concern.
Jeffrey Williams
Problems are opportunities brilliantly disguised as insurmountable obstacles.
How to post questions to get better answers faster
Managing Transaction Logs
January 22, 2019 at 7:07 pm
Jeffrey Williams 3188 - Tuesday, January 22, 2019 12:06 PMJeff Moden - Tuesday, January 22, 2019 11:52 AMSean Lange - Monday, January 21, 2019 2:49 PMI could easily put together a test in a VS project but it would horribly unrealistic. I can't even imagine a front end with a million rows of data. I don't care how fast your sql is, the performance to render to the UI is going to suck the life of everything including the person waiting for it. And of course the performance would vary significantly between a windows app and a web app.
The only reason why I'd do a million row test is to have enough to actually measure the outcome with. I agree that if a UI is having to address a million rows, then Murphy's half brother(Sum Ting Wong) is having a field day. It would just be to see if the front-end version would be a part of the "Death by a Thousand Cuts" and all such problematic code lends itself to.
Most front-end code is not going to apply the date formatting when the data is pulled - rather it applies the date formatting when the page is rendered. At that point - even if the .NET format code is inefficient it won't be visible to the end user (or even the developer).
We can see this in SSRS reports - which utilize the formatting code when the pages are rendered if you set the format for that column to any of the defined formats or a custom format. This formatting has a minimal effect...but then again, who is going to attempt to render a report with a million rows? If you do that - then formatting a date field in a report is not going to be your biggest concern.
Ok. So, not being a front-ender since before 2003, let me ask you. Where would a front ender use the .net format function? Only on the client or when they passed the data to the client? Would that mean only the client would "suffer" the FORMAT or would it be the Web Server?
Also, if someone writes an app to, say, process millions of CDRs (like I used to) from a ton of hefty telephone switches and they need to format the date and time in the file a certain way to meet the file formatting requirements for a 3rd party tax calculation system, that's going to qualify for much more than the trivial usage that you're suggesting. Applications and code outside of SQL Server isn't just to serve the RBAR nature of GUIs and the very limited scope of rows returned for reports.
It sounds like MS broke one of my cardinal rules when writing any code. They probably though of the low row usage like you stated and never even tried to make it faster because they didn't even think of such a possibility.
So, yeah... it's worth testing especially since they blessed SQL Server with garbage that supposedly lives in .net. If we can prove that it's seriously performance challenged in the application side of the house, maybe they'll finally take the time to fix it and we'll benefit.
Besides... who in their right mind would intentionally want to take 43 times longer for the round trip to the beer store no matter how fast the original ride could have been? 😀
--Jeff Moden
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply