Starting December 3, join live sessions with database experts and the Microsoft product team to learn just how easy it is to get started
Learn moreGet certified in Microsoft Fabric—for free! For a limited time, get a free DP-600 exam voucher to use by the end of 2024. Register now
Hi,
I currently have a dashboard based on 5 excels and 10 SharePoint lists. To increase the speed of this report I have done mulitple things:
After doing this the report is still quite slow. Note that the lists and excels are very small at the moment. No more than 10 lines each. With no query having more than 10 columns. I do have a fair amount of slicers on each page (around 6) and read that this could slow down performance. I also have some measures using the 'filter' function, but find no other way of writing them.
Does anyone have any experience with this? And how have you resolved it?
Kind regards,
Matt
What exactly is slow? Is it slow to load in the service, is it slow to refresh the queries, is it slow to add new measures? How many measures are in the data model? Do you have any table or matrix visuals that contain a lot of different measures? Do any of your measures use iterator functions like SUMX, AVERAGEX, etc?
Proud to be a Super User!
Hi,
Sorry for the unclarity. The report is currently slow in the desktop app. The refreshing is quite slow, but acceptable. The slowest part is the loading and filtering of the report through slicers. I have 4 tables that consist of the following type of measure.:
Weighted question 2 = SUMMARIZE('Performance Snapshot';'Performance Snapshot'[Team Member];"Weight question two value";SUMX(FILTER(ALL('Performance Snapshot');'Performance Snapshot'[Team Member]=EARLIER([Team Member]));
[Number of hours]/SUMX(FILTER(ALL('Performance Snapshot');'Performance Snapshot'[Team Member]=EARLIER([Team Member]));[Number of hours])*[Always on my team]))
These tables are used in half the visualizations, but are mostly not matrixes or tables.
I also have a measure taking date columns from different lists and combining them into one single date query as follows:
Formula: Date Slicer = DISTINCT( UNION(VALUES('Check-In'[End Date]);VALUES('Pulse Survey'[Modified]);VALUES('Performance Snapshot'[Modified]);VALUES('Career Aspirations'[Year]);VALUES('My Strengths'[Year]);VALUES('Firm Contributions'[Year]);VALUES('Goal Setting'[Year])))
Thanks for your help
Oh yeah, nesting multiple SUMXs inside a SUMMARIZE will definitely slow things way down, especially if there are a lot of rows in whatever you're SUMXing. As a first step, I would recommend installing DAX Studio and learning how to use that. You can run test queries to find out how quickly or slowly a particular measure will run, which will help you find the major sources of slowdown. Then you can focus on those measures and see if there is a more efficient way to write them. I'll play around with your example measures to see if I can come up with any better methods.
Proud to be a Super User!
God help us you have a SUMX with an ALL filter nested inside another SUMX with an ALL filter. I'm not trying to be mean but that's the DAX equivalent of replacing your car's oil with 5-minute epoxy. On every row of your table, your formula evaluates a formula on every row of the table. Inside that formula, on every row of the table, it evaluates another formula on every row of the table. It then uses these results to generate a summary table that includes every row of the table. You see the problem right?
It gets even worse when you put this into a visual. If you're putting this measure next to a column from the table, it must do all those steps a separate time for each member of that column in the visual.
It would help to see some sample data so I can get an idea of what kind of tables this is operating on. You can make something fake at mockaroo.com if your real data cannot be shared. How many rows are in this performance snapshot table? Also you're referencing several other measures inside this measure, so it would also be helpful to see the formulas for those measures.
Right off the bat I can tell you that the general pattern you're using is not as efficient as it could be, aside from the nested SUMX issue. Written generically, your measure follows this pattern:
SUMMARIZE( TableName, TableName[Column1], TableName[Column2], "MeasureName", SUMX( FILTER( TableName, TableName[Column3] = "examplevalue" ), CALCULATE(SUM(TableName[Column4])) ) )
That is almost always less efficient than this pattern:
ADDCOLUMNS( SUMMARIZE( TableName, TableName[Column1], TableName[Column2] ), "MeasureName", SUMX( FILTER( TableName, TableName[Column3] = "examplevalue" ), CALCULATE(SUM(TableName[Column4])) ) )
In your case the speed gain will be pretty minor right now, because the rest of the formula is slowing everything down so much. Still, the final form of this measure should still be switched to this pattern because hopefully we'll find a way to rewrite those nested SUMXs so they're not such a problem. I'll get back to you on the rest of it once I have a little more info from you about how it all works.
Proud to be a Super User!
@KHorseman Hi,
Sorry to bother you, but have you had some time yet to review my response?
Kind regards,
Matt
Hi @KHorseman,
Did you already resolve the problem?
I have impression that the reason for the performance issues may be he number of slicers (or filters) being used. I have a power Bi Desktop report with a bunch of filters ad dependencies (interactions) between the different visualisation and somehow the performance has dropped "proportionally" to the number of slicers and interactions being used.
Did you investigate anything in that direction?
Hi thank you for your fast answer. I did not know my DAX measures were the root of all evil. It was suggested to me on this very forum when I asked on some help on making it. Being a novice I did not think to think about the performance of it all.
So what I have is a table with one line for each performance snapshot. Each line contains information of the employee it's connected to as well as values for 4 different questions (question 1 and 2 have values between 1 and 5 and questions 3 and 4 are binary. A final column it contains is the number of hours related to the performance snapshot. Each question has a different 'weighted score' table where it has a column with the name of the employee and the weighted score for a question. This wieghted score is calculated the same way for each question. See the pictures below for more information. The first one shows what I want to achieve with the weighted questions. The second one shows how it's being done at the moment.
Thanks a lot already for your help, really appreaciate it
Hi @Matthias93,
It seems like I provide a low performance method, you can try to use below method if it has better performance.
1. Add calculate column and measure to get the current value.
Measure: calculagte the total hours.
Total =
var temp= LASTNONBLANK(Table1[Team Member],[Team Member])
Return
SUMX(FILTER(ALL(Table1),Table1[Team Member]=temp),[Number of hours])
Calculate column:
Current Value =
[Number of hours]*[Question 1 Value]/[Total]
2. Summary the table.
Summary table= SUMMARIZE(Table1,[Team Member],"Result",SUM(Table1[Current Value]))
Regards,
Xiaoxin Sheng
Hi,
I have another question regarding this topic. In my table I have a true/false column, would there be a way to get the weighted scores for all columns that contain true and false, a weighted score for only false rows and a score for only true rows?
Kind regards,
Matt
Hi @Matthias93
did you already solve this topics with weighted score. If not can you please explain a bit more in detail what are you trying to achieve?
One more question, any luck with the performance tuning and reducing slicers?
Hi Ermin,
I was able to solve this issue. For the slicer, I notided the report indeed became faster when leaving out some of them. Thanks for the tips.
Kind regards,
Matt
Hi @Matthias93,
I'm glad it helped.
However, the real question is how to get Power BI report to work fast with all the slicers needed. If you find a solution for it please feel free to share.
Regards,
Ermin
Hi,
I tried this and it seems to be working nicely. I have the impression performance has improved, but it can still be quite slow. This could indeed be due to the slicers I have on each page.
Thanks for helping me out!
Kind regards,
Matt
Hi @ Matthias93,
As said I have an impression that the number of slicers and dependency between the slicers and the charts play a significant role in the report performance. I have performance issues on one of my report although I don’t have any measures or significant calculations and the number of data is way lower than what I usually have. The only difference to my other reports is number of slicers.
Try duplicating your report to another tab then remove few slicers and test performance again. I’m sure that the performance will improve. This will just help you answer the question, Is it the number of slicers or the calculation intensive measure causing the performance issues.
If it is number of slicers, then we both have another issue which I have no clue how to resolve J. Maybe a new post or bug report to Microsoft will help.
Regards,
Ermin
Removing all slicers but one did indeed make the report faster, but still not fast enough in my opinion, especially when considering how small my dataset is at the moment. The slicers always cross-filter when you make a selection, this indeed eats up a lot of the performance.
Kind regards,
Matt
This measure does not use any other measures, all the calculations are made in one measure. Currently the Snapshot table consists of 4 lines, but in the future it will consists of several thousands of lines (5000-10000).
Thanks, I will have a look at this tool and try to make it more efficient as well.
Starting December 3, join live sessions with database experts and the Fabric product team to learn just how easy it is to get started.
March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount! Early Bird pricing ends December 9th.
User | Count |
---|---|
87 | |
86 | |
83 | |
65 | |
49 |
User | Count |
---|---|
127 | |
108 | |
89 | |
70 | |
66 |