10-12-2017 01:58 AM
A quick update on the memory release. I switched pages until the process had allocated 1500 MB. Memory was slowly released during the next hour until 990 MB was allocated and I stopped the test.
Opening the report, switching to the most demanding page and waiting one minute results in an allocation of 650 MB after a brief peak of 800 MB.
This report only has 2200 rows of data and the pbix file size is less than 2 MB.
10-17-2017 12:40 AM
There is a new update to the Oct 2017 release version 2.51.4885.701.
I used Marco's test file and ran a few tests.
1. Increased the number of reports to 4 by duplicating report 2.
2. I can see that between tabbing the reports the memory usage will gradually grow from 870 Mb to ~2Gb
3. Average load time per report increases from ~4 secs to ~12 secs
4. If you tab and wait, the memory usage drops by roughly 30% after about 40 secs of wait time.
5. If you do not wait for the memory collection to kick in, and continue to tab between reports, processor usage tops at 38% and memory about 2.1 Gb. Seems to not go over these limits as with past releases and crash.
Overall, the PBIX file seems stable but is still sluggish in rendering the custom visuals IMO.
10-18-2017 01:50 AM
I agree with the observation. Waiting you can see memory released, so the situation is definitely better.
It is still an issue in requiring 2GB to display a couple of report pages. This is a big penalty in many scenarios and I hope MS will do something to address that and to improve custom visual performance and memory requirements.
Marco Russo - SQLBI
11-08-2017 08:44 AM
11-09-2017 07:43 PM
Ignat, if we remove all the visuals the memory usage will be minimal, but the dashboard is useless.
It simply doesn't make sense that custom visuals are so expensive.
Requiring to reduce the usage of custom visuals to reduce a memory consumption issue is like saying that it is better to not use custom visuals to avoid problems.
This is not a good message.
11-28-2017 06:11 AM
I have the same issue with no custom visuals. Switching tabs accelerates the memory leak until I have to restart the program. This makes drillthrough useless because it relies on tab switching. I'm surprised more people aren't reporting this.