Early Access Report Customization became unusable for me as of R56.9

jmaino

@Quicken Kristina - tagging you as you've been helpful in getting reporting situations alike this resolved quickly.

My prior report (May 30) was closed, but the issue persists. I'm stuck using R55.26 for the time being. R56.9 broke the Early Access Customize Reports capability for me and the situation persists thru current R57.26 . I have a very large number of securities defined, and once moving to R56.9 or later, trying to select the "Securities" Tab when customizing a Cap Gains report takes over 3 minutes to populate the list. With R55.26, the list immediately populates, but R56.9 and newer, Quicken takes large amounts of CPUtime and just sits there. Turning off Early Access Report Customization -partially- resolves this for me - that takes only 8-9 seconds to populate the list, but still not immediate as it is in R55.26 . So it appears that something introduced in R56.9 slowed things down dramatically wrt: the processing of the list of defined securities.

I've sent a couple of reports thru Quicken of the problem.

Is anyone else experiencing something similar?

Quicken Kristina

Hello @jmaino,

To assist with this issue, please provide more information. Are you noticing this only when customizing the Capital Gains report, or are there other reports with the same behavior? I can partially replicate what you're seeing, although, since my file doesn't have a lot of securities, the delay is barely noticeable. I notice that once it loads the first time, it the securities tab comes up instantly afterwards until I close or re-run the report. Is that what you're seeing also?

I look forward to your reply!

jmaino

Hi @Quicken Kristina

First - thanks for the quick action and response - I really do appreciate knowing that people are working on this, and communicating their findings and progress!

I believe that what you have replicated is likely the same as what I'm seeing, but the actual delay(s) will be based on the number of securities/complexity of the security transactions themselves.

I not only see this with the Capital Gains report, but also with Investment Performance report, so I expect it impacts most security-based reports. As soon as I click the "Securities" tab, we go into this minutes-long delay.

The first time I click on the "Securities" tab, I experience the severely long delay… but if I switch to another tab and then go back to "Securities", I still experience a long delay of about 25seconds, but it's much faster than the first time. Once I close the Configuration dialog, if I re-open and try again, I also begin with the minutes-long delay.

Your more-or-less instantaneous subsequent refreshes vs my 25-second refresh is likely due to a far-smaller set of securities than I have, but I believe you're on the path to seeing exactly what I am - especially if your dataset behaves differently between R55.26 and R56.9 and if it behaves differently between the Early Access Report Customization and the "old" style in R56.9 and beyond. With my large set of securities, even the "old" style has an appreciable delay, but it measures in seconds in R56.9. Both old and new style customization paths are virtually instantaneous in R55.26 .

I thank you again, and in advance, for helping drive to a resolution.

Quicken Kristina

Thank you for the additional information,

I forwarded this issue to the proper channels to be further investigated. Thank you for submitting a problem report with log files attached and a sanitized copy of your data file!

While you will not receive a response through this submission, the report will help our teams in further investigating the issue.

We apologize for any inconvenience!

Thank you.    

(CTP-10524)

jmaino

Thank you @Quicken Kristina - I had submitted reports thru the app with a sanitized version of the data, both while using R56.9 when originally reported in May, and again before this thread using R57.26 .

jmaino

@Quicken Kristina - I can confirm that this issue has been resolved as-of R58.8 (today).

Thank you so much for helping to drive this to resolution.

Quicken Kristina

Thank you for the follow-up,

I'm glad to hear the issue is resolved in the new update!

If you need further assistance, please feel free to reach out!

UKR

I have a very large number of securities defined,

@jmaino
just curious … how many securities do you have in your Quicken data file?
To find this number easily, in Quicken click on Help, then Shift+Click on About Quicken.
The resulting File Information display will have this number.
If you would, please capture an image snapshot of this display, black out personal information near the top of the display and then attach the edited image here.

jmaino

@UKR - nearly 20k. This comes from years of active options trading.

I know that there are many aspects of Quicken that suffer (performance-wise) from this situation. Even simply starting up w/ an empty investment register causes a delay of a few minutes, showing me these types of dialogs.

I really have not been able to guess at what in the world Quicken thinks it needs to recalculate or check each time quicken starts - but it does - and it's painful. It clearly does not appear to be looking ONLY at securities that were ever held in any individual investment account, because this delay is experienced repetitively once I switch accounts within an open Quicken session. I have cloud sync turned-off, and for stock options, I have also disabled all Download Quotes. For stock options past expiration, they are set to "Hidden" in the securities definition.

Unfortunately, I have not found an acceptable way (yet) to remedy things and reduce the size of the security-set that Quicken deals with. I also think there's more that Quicken could do on its own to improve this, but I don't really think that's a priority for them. I'd gladly volunteer to partner with them if they expressed such interest.

Attempting to split-off older transactions into separate QDF's files isn't really something I want to pursue (at this time).

Q97

You might want to try Archive Investment Transactions to see if that improves the performance (after backing up your data file)

How To Archive Investment Transactions To Improve Performance | Quicken

jmaino

@Q97 - thanks. Long before this functionality became available, I began doing this on my own - at the beginning of each year, I create a new investment acct and transfer positions from the prior year's account into the new one, so that my new year's acct has only open/active positions. So even with an investment account that mimics the behavior of the Archive flow and has substantially fewer closed positions than the size of the defined security-set, the slow performance and delays are still experienced in several parts of Quicken. I'll consider trying the Archive flow, however, to see if that somehow improves things for me.

But, as I said above, it -appears- as if Quicken wants to do something on the whole of the defined Security-set upon startup and/or changing investment account registers b/c even with a wholly empty new investment account, this delay when opening the register is still seen. It does not appear as-if it's efficiently looking ONLY at those securities that were ever held in the investment account being selected, which I believe would improve things a lot. (I just created a new, empty Junk investment account - it took quicken about 3-minutes to open that register while telling me it was 3% through/4% through/5% through "Checking Securities").

q_lurker

I feel pretty comfortable saying your program performance issue is your number of securities. 20K is perhaps 5 times more than any other report I recall. Quicken has claimed for a long time a ‘soft’ limit of 2,000 ‘tradeable’ securities (but never clarified the soft or traceable terms). The program was just never built for that level or type of use.

Some other program for your trading activity is the only solution I can see.

jmaino

Thanks @q_lurker - and I agree. However, I believe there's a mix of fixable and non-resolvable issues that are impacting the behavior and efficiency.

Even though a rare use model, it doesn't hurt to bring to light and request improvements, and I think the user community should challenge the code to ensure that it's efficient wherever possible. Case in point - the issue that started this thread. Surely someone introduced less-than-optimal coding in R56.9, which was thankfully fixed in R58.8. How many other cases like this might there be, that we dismiss simply due to the size of the Security-set? We may never know - but the Quicken team has a sanitized version of my db, and I hope that they can use it to expose and differentiate between resolvable and non-resolvable issues related to this.

Dealing with existing issues due to the size of the security-set is one thing - and resolving those should be seen as Enhancement requests.

But, I'm hopeful that both the community and the development team understand that introducing new issues related to the security-set is something that, if and when ID'ed, should be treated as Bugs that never should have been introduced.

I'm very thankful for the team's response to the case that started this thread, and hope to see this type of collaboration in the future.