nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Are there any plans to rewrite Quicken for Windows for modern standards? Modern DB.

mikek753b

Are there any existing plan to modernize Quicken for Windows?
Any ETA?

The main issue that current Quicken performance extremely depends on the data file size and number of accounts, transactions.
When such old data structure file will be replaced by a modern DB?
Current only option to work is to trim datafile.
But, such trim option doesn't work for Investment accounts, where I need over 10 years transactions to be present.
Yes, I have "old" Stock, ESPP, 401k funds and etc.
To be clear → this isn't my Windows HW performance issue.
I use Gen4 NVMe Storage, 32 GB RAM, CPU turbo with above 5GHz
Current Quicken doesn't use multi cores, it even isn't multithreaded much if at all.

Find more posts tagged with

Windows

Performance Issue

Accepted answers

Chris_QPW

Just a note, if you want to get a better idea of what threading is being done without digging into too deep, switch to the logical processor view. That way you can at least see if one core is being overwhelmed by the fact that Quicken isn't using threads very well. But to really track it you need to use that tracks threads by process. But that in fact tells nothing about performance problems with a database.

But if my guess is right, for most performance problems, even though I agree that Quicken makes poor use of threads (they have to be using some just to have a GUI) I doubt that is the problem.

This is sort of like the people that think that you can recompile using 64-bit and magically get high performance.

I'm pretty sure the performance problems relate to these areas:

Waiting on something like the network.
Badly structured GUI objects and use.
Badly structured code for use in a multiple thread environment.

In other words, in relationship to threads, you can't just "put in a modern database" you need to structure your code almost from the beginning in a way that will take advantage of it. It is really completely different mindset.

I think if the developers really want to improve Quicken Windows' performance, they should be profiling the code and finding the bottlenecks and fixing them. I'm sure there would be plenty of gains from that. But the truth is that most organizations have long given up/forgotten/never learned such skills. Developers have been relying on "the machine will get faster, so it doesn't matter if I stick in more layers" for many years now. And the truth is that the processors haven't kept up with this idea.

Boatnmaniac

@mikek753b - Whether Quicken, Inc., will ever redesign or significantly change the Quicken Classic platform (including the DB) is something we likely will never know until it is released. Their standard protocol is to not inform users of any significant planned changes (unless it is a Product Idea in this forum) nor the timing of them until they are actually released….or once in a great while, not until very shortly before they are released.

The replies posted above are best guesses based upon their understanding of how Quicken has operated in the past and upon their knowledge of Quicken Classic and the history thereof. Personally, I agree with them in part because Quicken is a small company so they don't have extensive engineering resources to fall back on to undertake such a massive program development effort…at least not to be able to do that in any kind of short-term window. In addition, while Quicken is definitely committed to continuing to support Quicken Classic for both features development and product fixes and performance improvements, it appears to me that perhaps their long term objectives might (just my guess) be more aligned with ongoing development of their cloud-based application (Simplifi) since that appears to be the trend of most software companies, including financial planning applications. All I can say is we'll just have to wait and see what happens.

If you really want to push Quicken on something like this you can post this as a Product Idea. That will give other users the opportunity to review and, if they agree, cast their vote for it. If/when there are about 50 votes cast in favor of the idea, the Product Development team will usually take it into consideration and provide feedback on whether or not it will be added to their product development plan. That will provide, perhaps, the most definitive answer to your question that we will ever see.

All comments

NotACPA

Wouldn't bet on it. It's taken YEARS to re-write QMac, and they still haven't caught up with either QWin or where QMac's predecessor was.

I doubt either of us would still be alive in the time it would take to re-write QWin.

miklk

We need to be grateful they keep Quicken going best they can…

Chris_QPW

But if my guess is right, for most performance problems, even though I agree that Quicken makes poor use of threads (they have to be using some just to have a GUI) I doubt that is the problem.

This is sort of like the people that think that you can recompile using 64-bit and magically get high performance.

I'm pretty sure the performance problems relate to these areas:

Waiting on something like the network.
Badly structured GUI objects and use.
Badly structured code for use in a multiple thread environment.

mikek753b

so. looks like it will not happen any time soon, if ever

Yes, it would take to rewrite new foundation framework to use Event Driven and Async programming, instead of current sync blocked calls.

Especially that a few processes can access Data concurrently, this where modern DB (relational with strong consistency) would help big time.

As result modern multi cores CPU would be used for full potential.
In my dream such new DB would allow SQL like query that can run in parallel or on schedule for reports, and many other usage.
Think about creating custom DB Table View for Custom View in the Quicken. So, will no needs to ask Quicken to develop one or another View or Report, and so many each User specific wants.

Boatnmaniac