App Time-to-Exit heavily affected by Saved Sessions

[howiec]

Hi,

After some quick troubleshooting I found out why it was taking several minutes to exit PDF XChange Editor.

Having too many &/or too large (# of docs) saved sessions significantly slows down exiting the app… like a LOT.

Is there something in the way the app saves/checks/processes/updates saved sessions that could be avoided or optimized?
Saved Sessions is a very nice feature but artificially limiting the size & # of saved sessions is a major feature handicap.

Thanks!

Howie

[Daniel - PDF-XChange]

Hello, howiec

Thank you for the report, Could I possibly ask for an export of your settings, specifically, with the "sessions", and "common" boxes checked. The sessions data will only contain file names, and paths (not the documents themselves), but just incase there is anything sensitive there, please email Support@PDF-XChange.com with a link to this post, and "ATTN:Dan" in the subject line.

Beyond that, I have already passed this report up to our Dev team for review, and will be sure to get back to you as soon as I have heard back from them. Hopefully they have an idea of what can be done, or know a way to log this data without gathering multiple GB of information to sift through.

Kind regards,

[howiec]

[...]export of your settings, specifically, with the "sessions", and "common" boxes checked. The sessions data will only contain file names, and paths (not the documents themselves)

Hi Daniel,

I just sent the email with the requested files/data.

Note that exporting settings does not include the saved sessions. I exported 1 sample saved session. If I load that session & save around 10 more of those, the app takes around 2min 30sec to fully exit (check Task Manager).

Thanks,
Howie

[Daniel - PDF-XChange]

Hello, howiec

Thank you for those, I received them and began some further testing on this end, even after importing your settings however, no delay was present on my end, the Editor seems to close instantly...

I did some extended testing for this over the past day, making well over 100 sessions with ~300 documents in each, even with those present alongside your settings and the newly added example session (duplicated 10 times as you suggested), the Editor still closes in under 2 seconds on this end.

You mentioned in your email as well that:

On a separate note, there seems to be some setting that's causing the app the take around 1min 20sec to start even with the history cleared, no saved sessions, & no files opened/to-restore.
Maybe after work I'll test resetting the settings to see if that resolves the issue but I'm curious to see if others can reproduce that too.

Since I was unable to reproduce this on my end using your imported settings, I can say that this is not likely a setting issue on our end, but at this juncture I cannot think of what else could be causing this kind of delay when these items are entirely empty...

I have added these notes to my report for the Dev team, and once I have some input from them, will be right back to you with a followup test.

Kind regards,

[howiec]

I received them and began some further testing on this end, even after importing your settings however, no delay was present on my end, the Editor seems to close instantly...

I did some extended testing for this over the past day, making well over 100 sessions with ~300 documents in each, even with those present alongside your settings and the newly added example session (duplicated 10 times as you suggested), the Editor still closes in under 2 seconds on this end.

Thanks for looking into this Daniel.

In my case the app "exits" relatively quickly but the program/process doesn't fully close.
The app window/GUI closes but the .exe stays open consuming CPU cycles, etc. which can be seen in Task Manager.
Obviously this could be an issue say when shutting down the PC which could end up with force-killing the process such that the state isn't saved (similar to a crash in that sense).
The "real" time to fully exit seems to scale somewhat with the number &/or size of the saved sessions.

I have added these notes to my report for the Dev team, and once I have some input from them, will be right back to you with a followup test.

I'll see if I can reset settings 1-by-1 to see that's related in my case for both of these issues.

[howiec]

Looks like I found the culprit or at least part of the problem (not necessarily root cause) for the long start-up time.

Only after resetting "Common" under "Program Options" did the Document Recovery side pane pop up showing 7.42GB of recovered documents data.
Each document recovery data size seems to be a consistent 256kB which means there was approx. 30,000 documents of recovery data being auto-saved.

So if the "Keep recovery info..." setting is checked & the "Show Recovery Panel..." is unchecked, then the data keeps growing potentially forever or until things slow down to a crawl / crash or some recovery data is deleted.

After deleting all of the recovery data, the app starts up quickly within a few seconds or so depending on how many documents need to be re-opened of course

Screenshot 2025-07-15 124848.png

.

So maybe there needs to be a way to limit or archive the recovery data or minimize the startup parsing of that recovery data, data structure / database.

====================================================================

Regarding the long time-to-exit the process, I just did a test when I compared 1 saved session of >400 documents vs 10 additional duplicate saved sessions (11 total) vs 5 total:

Task Mgr shows approx. 16% CPU avg while closing the process.

11 total saved sessions:
2min 23sec to fully close the process

5 total saved sessions:
1min 25sec to fully close the process

1 saved sessions:
32sec to fully close the process

Thanks,
Howie

[Daniel - PDF-XChange]

Hello, howiec

Okay, I managed to reproduce the issue, what I was missing was a check of the task manager. I hadn't scrolled down far enough to see it running in the background as you mentioned. I am very sorry for that. For now, I have shown the issue firsthand to the Dev team, and we will be invesitgating the sessions relation to this issue now that we have a reproducible process available.

Regarding the issue with recovery data. That endless growth would be expected if you have that option enabled, and have not been choosing to delete or use the recovery data after you see it. Sadly it is simply impossible to pick between these two options, so you can either keep it all (with manual deletion needed) or you can keep it only as long as needed, and then have it vanish if you don't use it in time.

Kind regards,

[howiec]

Thanks Dan.

Re. the Recovery Data issue, I understand the tradeoff.

Even if there's no safeguard or user-configurable limit to the recovery data size/# of docs (e.g., like a rolling data limit where oldest data is deleted / overwritten first), then some sort of warning or note in that "Save Documents" section for the performance degradation over time should be included.

Otherwise you'll have your most hardcore, professional, or heavy-use customers run into headaches like this trying to troubleshoot things or just give up on this otherwise great product in a commercial/enterprise setting where you would make the most revenue & profit.

[Daniel - PDF-XChange]

Hello, howiec

In that line of thought... It is highly uncommon for the software to be suffering from enough rapid-fire errors that these accumulate to such extremes in the first place, and Resetting settings, reverts this option. Which would prevent that issue from continuing, and should generally be one of first things anyone tries when they start experiencing errors like slowness.

Beyond those two points, you were only able to experience this niche issue becuase of a rigorous testing process, which essentially enabled a "forced crash" scenario that caused this data to be saved repeatedly, while multiple instances of the software were running, which shouldn't normally be possible (and may have duplicated this data further).
If someone did continue using the software in a situation where there were this many crashes occurring They have should probably reached out to us to address either the crash itself, the slowness, or to for help recovering their lost work, becuase they disabled the option to show it, long before this would become an issue.

If we assume they ignored all of that and never reached out for help, I expect they would be leaving due to constant crashing and "data loss", long before any "slowness" that occurs after a few dozen crashes with numerous files experiencing lost changes in each crash.

I will mention it to the dev team, but the steps required to encounter that slowness specifically, make it somewhat of a non-issue, or at least, and extremely low priority item.

Kind regards,

[howiec]

In that line of thought... It is highly uncommon for the software to be suffering from enough rapid-fire errors that these accumulate to such extremes in the first place, and Resetting settings, reverts this option. Which would prevent that issue from continuing, and should generally be one of first things anyone tries when they start experiencing errors like slowness.

Beyond those two points, you were only able to experience this niche issue becuase of a rigorous testing process, which essentially enabled a "forced crash" scenario that caused this data to be saved repeatedly, while multiple instances of the software were running, which shouldn't normally be possible (and may have duplicated this data further).
If someone did continue using the software in a situation where there were this many crashes occurring They have should probably reached out to us to address either the crash itself, the slowness, or to for help recovering their lost work, becuase they disabled the option to show it, long before this would become an issue.

If we assume they ignored all of that and never reached out for help, I expect they would be leaving due to constant crashing and "data loss", long before any "slowness" that occurs after a few dozen crashes with numerous files experiencing lost changes in each crash.

I will mention it to the dev team, but the steps required to encounter that slowness specifically, make it somewhat of a non-issue, or at least, and extremely low priority item.

It's totally up PDF-XChange to prioritize issues as they see fit depending on how much time & resources are available. Run your business how you want, & reap the results - good or bad.

Now, as a paying user, I don't expect the software to be perfect but I also don't expect to need to reset all my custom settings & try to spend hours troubleshooting every time I encounter a bug or scenario that's not anticipated or not mitigated.

Having robust software isn't just for me, this is for all of your customers. I could care less at this point if the issues are fixed now that I know of the workarounds or pitfalls. The low-hanging-fruit mitigation is for all other customers & future users.
Not everyone has the knowledge or determination or time to troubleshoot the problem themselves &/or post in the support forums unless it's seriously affecting their work or a large number of users.

I've been dealing with several of these issues for months now & the only reason I'm posting about the issue in these forums is because it's become serious enough & that I think that the app is overall great. If I didn't think it was overall great, I would have simply stopped using this app instead of posting in the forums.
It's taken months for me to post because like everyone else, I'm really busy with work too...


To be specific in this topic/thread, there are 2 different issues:
(A) Slow start-up (~2.5min) with those ~30k documents of recovery data accumulated over roughly 5months of regular work use (this issue started getting noticeably significant a long time ago).

(B) Slow exit (~ 6min) with all the large saved sessions I had. This happened within a month after I started saving my sessions for "backups" & custom workflows. I never expected that to cripple the application exit time.

My comment was with regards to (A). A simple, low-hanging fruit message/mitigation would help prevent this issue with minimal coding/effort, even if the root-cause is not addressed.

Alas, it was just a recommendation, not a demand.
When I encounter great tools, I tend to recommend them to colleagues, businesses, & friends but I don't hide the flaws either.
I hope that PDF XChange becomes the de facto tool over Acrobat Pro or other products. Your advantage is in the ease-of-use for average users, customization & adv. features for more power users, & hopefully robustness. I'm on your side.

[Daniel - PDF-XChange]

Hello, howiec

I have some good and bad news:
- The good is that I have heard confirmation, CaseB, will be seeing some action, however...
- The bad news is that, due to its particularly specific requirements, it is somewhat of an edge-case, and will see a lower priority. I do not believe it will be resolved in time for our next release, as there are higher priority issues and our dev team is already stretched thin.

In the meantime, this one is avoidable as you said, by "artificially limiting" sessions stored in the application. I should note that you can always use the "session file" save method instead of adding a new items to the application sessions list. This has the benefit of not being loaded alongside the app, and in turn not being saved to the registry at closing time. These session files can then be double clicked from your desktop or other locations, to immediately open the referenced files in the Editor.

Beyond that, to prevent the issue with CaseA, I would advise you uncheck the "keep recovery information" checkbox, or enable the "show recovery pane" option, and review/clear our data you are not using.

Kind regards,

[howiec]

Hi Dan,

Thanks for the update.

No worries.
In the meantime, now that I'm aware of the issues, I can just work around them by exporting/importing large saved sessions as needed & manually deleting recovery data & disabling the "Keep recovery information when closing and discarding changes" option for now.

Regards,
Howie

[Daniel - PDF-XChange]