Performance issue when this Measure is applied to Filter (on Matrix visual)

There were a few things throughout your measures that were slowing down your report - I didn't check to see what had the most impact, so with no particular emphasis:

ClientD_M1 = count('vw_census_trend1'[ClientID]) + 0

1) Usually it is better to avoid adding zero like this as it means the measure will never be blank - i.e. will get evaluated/displayed everywhere. This can impact performance. I did a quick search and this post has a good explanation of this: https://community.fabric.microsoft.com/t5/Desktop/Adding-0-on-Measure-Directly-Impacts-Performance-Memory-Issues/m-p/649979/highlight/true#M311701
Note: if you are only using this over an iterator, then the performance issue is mitigated as you are only evaluating for each row of the iterator within the filter context (so you will get blanks when the table you are iterating over is empty in filter context). The solution I shared took this further by also checking up front to filter out cases where we know that no census data exist.

2) It makes sense to use COUNTROWS instead of COUNT in a case like this because a) it reflects the intent better, I think (are we interested in the count of all non-blank IDs or the count of applicable census rows), and b) COUNTROWS is a little more efficient than COUNT so as a general rule it is better to use unless your specific scenario calls for COUNT. The performance difference is not big, though (difference of milliseconds in most scenarios), so you could argue it's just preference. This is actually covered in official docs: https://learn.microsoft.com/en-us/dax/best-practices/dax-countrows

AverageNew = 
AVERAGEX(
    FILTER(
        SUMMARIZE(
            'vw_census_trend1',
            DimDate1[DateFormat],
            "ClientD_M1", [ClientD_M1]
        ),
        [ClientD_M1] > 0
    ),
            [ClientD_M1]
)

3) This measure is sort of doing the same thing three times in the first argument of AVERAGEX. SUMMARIZE( 'vw_census_trend1', DimDate1[DateFormat] ) by itself gives you all the DimDate1[DateFormat] for which related 'vw_census_trend1' rows exist. Thus, adding a column where you are counting related 'vw_census_trend1' rows and then performing a >0 filter on that is adding a couple operations to achieve something that's already been accomplished. Check out this on more info on SUMMARIZE + note the warning on using it to add columns: https://dax.guide/summarize/

4) The outermost AVERAGEX component is what you are really after. It's very close to the solution that I shared. You do, though, have the issue where you are only iterating over "DimDate1[DateFormat] for which related 'vw_census_trend1' rows exist" - e.g. if filter context of visual in a Date Total column is { Jan 1, Jan 2, Jan 3 } but you only have census rows related to Jan 2 and Jan 3, then Jan 1 won't be included in the table you are iterating over. I.e. this is why your measure wasn't factoring in days where count was 0. Or maybe that's what you wanted, in which case this is not an issue at all.

decimalFixNew = 
if(DISTINCTCOUNT(DimDate1[DateFormat])=1,
format([AverageNew],"0"),
format([AverageNew],"0.0")
)

5) What you are looking for here is HASONEVALUE, which you probably saw we used in the dynamic format string. You can probably immediately see how this would perform a lot better: checking if given column just has a single value in filter context VS performing a distinct count on the whole column within filter context and then checking if it's =1. 

6) Another issue here is that FORMAT( BLANK(), "0" ) will evaluate to "" not BLANK(). This is why you were seeing "blank" rows with this measure. Besides not being what you wanted, this would also have a performance impact.

7) To be clear, converting this measure to a dynamic format string I don't think should have improved the performance at all. The gains related to this measure came from the two points above

decimalFixNewAdd = IF([decimalFixNew] <> BLANK(), 1, 0)

8​) As noted above, this shouldn't be needed if you fix the FORMAT issue noted in #6. And for what it's worth, you could have forgone making another measure and just did a 'is not empty' filter on [decimalFixNew]. I don't think that would have made a difference performance-wise, though

MarkLaf I would like to follow up on my two questions.