SWP files removal

[tdgm]

In older post suggested above I just sent a message because I am having that same problem discussed and even tried teh MacCleanse software to no avail but I might not have used it right to find orphaned files. If any one has any suggestions I woud REALLY appreciate it. The delay is fustrating. Since on 2 comouters with similar problem my thought is it is a Mac problem and  not PI
Steve

[RickS]

On my Windows machine looking at the task manager PI never takes more then 5 seconds to exit completely. Now I do have PI the executable and all PI associated folders including swap folders excluded from my virus protection. Maybe that is why I have no delay.

That's interesting, Mike.  I'll have to poke around a little and see if I can figure out what it is doing.  I have heard others report the same thing but don't remember if what platform(s) they were talking about.

I have some pretty big projects with lots of large drizzled images.

[pfile]

one thing about OSX is that the default location for PI swap files (/tmp) is hidden from 'ordinary' users, and so there's a cron script that runs weekly (IIRC) that blows away everything in /tmp. the reason being that if programs put temp files there, it could fill up with no way for a user without knowledge of terminal.app to free this space. rebooting also clears out /tmp.

this caused me some trouble at some point because you can't save a project if the .swp files have been removed. i edited the script which cleans up /tmp to exclude .swp files from the deletion and all was well.

obviously if you have defined a custom swap file location(s) then as long as /tmp was not one of the directories, OSX won't ever delete your .swp files.

rob

[tdgm]

As the originator of this subject I have followed this and link described in the posts and tried different suggestions to no avail Still with increased opening and closing times. Just opening PI from icon and not a project from push of button to completely open 65 secs. Closing empty project 55 secs and actually closing a large project took 65 secs. Opening a project is large especially if a large project. Computer is a Mac Book Pro Mid 2015 9 months old 4 quad laptop with 16 gb of RAM and a SSD.

Now even though I have not measured times on my other computer but it also acts exactly the same. this computer is a Mac Mini 2014 with only 4 MB Ram and a single processor.

So any suggestions


steve

[mschuster]

You might try resetting PI settings. Launch PI with the Control key held down (if you see a popup menu, click Open with the control key down), then click Yes and then relaunch PI.

Very occasionally I see slow PI performance on my iMac and reset solves the problem. You do loose settings and configurations however which is annoying.

Thanks,
Mike

[tdgm]

Mike

Thanks Bingo resetting PI worked now it fly's on opening and closing

Steve

[msmythers]

What would be good would be if someone who still has the problem could make a copy of what ever files have the PI parameters before resetting. Then Juan could check those files against the default parameters to see what is happening.


Mike

[tdgm]

What are those  files?

Steve

[Juan Conejero]

Just opening PI from icon and not a project from push of button to completely open 65 secs. Closing empty project 55 secs and actually closing a large project took 65 secs.

This does not happen on any of my working and testing machines, including a variety of Linux, FreeBSD, Windows and OS X versions running on physical and virtual machines. If you have several GB or maybe TB of swap data because you are working with large images and projects, obviously PixInsight needs some time to remove them. Other than that, the application starts very quickly and exists in just a few seconds after rewriting its configuration file. If you have been working with many tools and complex scripts, the configuration file may take a bit longer to update, but again that should be just a matter of seconds, never minutes.

Are you using an antivirus application?

[tdgm]

Hello Juan

NO AntiVirus but Firewall is on. Happens on 2 different machines. On 1 machine I reset PI as suggested on this post and the problems seems to be resolved have not done it to the other machine yet incase any one wants to see some log files or what.

Steve

[aworonow]

When I process on my laptop and exit PI, it is ready to restart in a few seconds. On my 'all-in-one' it takes, maybe, 2 minutes to be ready to restart. Both machines run Win 10.

Alex W.

[pfile]

i had PI open for a few weeks and just quit out of it.

it took maybe 2 minutes to shut down. i sampled the process and whatever it's doing seems to be settings related, looks like the destructor for QSettings is what's taking so long. there are a zillion stack frames under that call... so maybe this does not have anything to do with deleting swap files, unless they are deleted by that destructor.

rob

[mschuster]

Rob,

Yes, your problem is consistent with mine, it may be setting related. If so a reset will help. I am thinking of making a script change to stop using settings as a cache to avoid large setting files and these problems.

Thanks,
Mike

[Juan Conejero]

i sampled the process and whatever it's doing seems to be settings related, looks like the destructor for QSettings is what's taking so long.

Yes, I am aware of this performance issue, although it isn't as problematic in my tests as you have described. I will fix this issue in the next version. A possible solution is to generate separate settings files for each script and tool. This should keep the main settings file, the one used by the core application, much smaller. This also has the advantage that the whole settings system would be more modular, so for example you can perform a reset of application settings keeping all script and module data intact. Another solution is to cease using Qt for these tasks and write my own thread-safe settings engine using pure PCL code to generate binary data, which is not too difficult. I am still looking for the optimal solution.

[pfile]

thanks Juan, yah it does not seem like a high priority issue. as usual i had a lot of images open and had used all sorts of processes over those weeks... my use may not be typical.

rob