Windows programs in general.

[Derpy Hooves]

Hey all, I have noticed that some programs will slow down over time. I tried doing a Google search on it, but there was only stuff about why Windows as a whole slows down. So I was wondering if anyone knew why individual programs may slow down after awhile?

Examples:

• I created an image in GIMP, rotated it by twelve degrees, and saved it as another image (I was creating a "Loading" type .gif @30FPS for a one second animation), and after a few times, it would slow down to the point where GIMP would crash.
• Antivirus scans seem to slow down the longer they run

That's all I have from personal experiences that I've recently noticed, so if anyone else has noticed it too, it'd be nice to know that I'm not just going crazy or not thinking about it enough.

Additional information that someone may find useful: 3GB RAM, 2.20GHz dual core processor (Intel Core 2 Duo t7500), 32-bit Vista

[BC_Programmer]

Usually it's because of bad resource management. The typical cause is when a program has a "cache" of information.

A very good example of this is Firefox. FF's memory usage balloons like the girth of a pregnant sow after you start it. The primary cause is simply that FF cache's too much information- all the tabs keep track of a lot of information on previous pages, and keep that in memory, "just in case" you go back. GIMP keeps track of your actions for Undo buffers; usually every change you make can result in a complete copy of the bitmap itself being copied into RAM (Photoshop, in contrast, saves the specific occurrence that was performed in a reversible manner so it can be undone, but without requiring the entire image to be saved).

For AV scans, as the scan progresses the AV program will have loaded more data; as it looks through files, it has to load them all into memory, examine them, and remember anything it found as well as what it found in them, meaning their memory usage goes up.

Sometimes time isn't even the variable. For quite a long time I've had this issue with photoshop where every tool would take about 4 seconds before it would start to "work"; zooms, brushes, etc. I thought it was because of the above and PS was just being sluggish, since restarting it fixed the problem.

But I managed to figure out that the true cause was Photoshop's dealing with removable devices. Occasionally I would save to a removable device, and when you save to a drive Photoshop for whatever reason keeps a lock on the drive (in my case, "safely remove" would insist the drive was in use). if I removed the drive myself, Photoshop would become sluggish. I don't know why, specifically, but a guess would be that it was trying to access the removed device for whatever reason. Similar things might cause it in other applications.

For the most part though this type of thing is either because of a genuine bug (such as a memory leak in the program) or because of bad caching of data, which is really just another name for a memory leak.

[Derpy Hooves]

Usually it's because of bad resource management. The typical cause is when a program has a "cache" of information.

A very good example of this is Firefox. FF's memory usage balloons like the girth of a pregnant sow after you start it. The primary cause is simply that FF cache's too much information- all the tabs keep track of a lot of information on previous pages, and keep that in memory, "just in case" you go back. GIMP keeps track of your actions for Undo buffers; usually every change you make can result in a complete copy of the bitmap itself being copied into RAM (Photoshop, in contrast, saves the specific occurrence that was performed in a reversible manner so it can be undone, but without requiring the entire image to be saved).

For AV scans, as the scan progresses the AV program will have loaded more data; as it looks through files, it has to load them all into memory, examine them, and remember anything it found as well as what it found in them, meaning their memory usage goes up.

Sometimes time isn't even the variable. For quite a long time I've had this issue with photoshop where every tool would take about 4 seconds before it would start to "work"; zooms, brushes, etc. I thought it was because of the above and PS was just being sluggish, since restarting it fixed the problem.

But I managed to figure out that the true cause was Photoshop's dealing with removable devices. Occasionally I would save to a removable device, and when you save to a drive Photoshop for whatever reason keeps a lock on the drive (in my case, "safely remove" would insist the drive was in use). if I removed the drive myself, Photoshop would become sluggish. I don't know why, specifically, but a guess would be that it was trying to access the removed device for whatever reason. Similar things might cause it in other applications.

For the most part though this type of thing is either because of a genuine bug (such as a memory leak in the program) or because of bad caching of data, which is really just another name for a memory leak.

Huh...interdasting. I should have watched how much memory the AV scan was using when it started, and how much it was using after it started noticeably slowing down. With GIMP, I checked it when it was slowing down, and again after a fresh restart of the program, and there was hardly a difference. So that was kinda odd. I didn't think about caching. And when you're  consecutively making thirty copies of an uncompressed image, things will add up quick.  I would think some programs would do a slightly better job at (What memory clean up is called in Java) garbage clean up.

I know I was going to say something more, but I don't remember; so I'll just leave this here.

Twilight is best pony.

[BC_Programmer]

Re: memory usage, Task manager doesn't show you everything. Because of the way memory is managed there are quite a few values that one would need to inspect. Also, some programs "preallocate" a bunch of memory for some reason, but they will only really slow down when more of it is used. (the "fail" of this is that they are trying to do the task that the memory allocator is supposed to be doing).

A good tool for this sort of analysis is Process Explorer. It can provide columns for various memory information on each process- Minimum and Maximum Working Set, Current Working Set, Shared Bytes, Private Bytes, and the number of GDI and USER handles... which actually brings me to another common cause: leaked handles.

With Windows drawing, things are usually drawn using Pens and Brushes. When a application uses a brush, it has to remember to delete it at some point; same with Pens, bitmaps, etc. If it doesn't clean it up, it leaks that handle. Pens and Brushes (and I believe Fonts) are GDI resources. In older versions of windows, there weren't very many handles to go around and you could easily tell when a program was misbehaving because everything would be affected (Windows might start drawing things in the default font, as one example).

The thing that makes restarting fix this is that With Windows NT, process termination will properly destroy all the leaked handles, too.

Leaked handles over time can cause slowdown because operations on other handles now cause GDI32 or User32 to sort through the leaked handles, because as far as they are concerned they weren't deleted and therefore they must still be being used for something.

Process Explorer can show GDI and user objects; I believe Task Manager can as well, so you can take a look at that next time and compare the numbers.


The Device thing for me has always been a common cause, though I've had Visual Studio become unresponsive after a few days of uptime that can only be fixed with a restart (though it is often using 1 or 2 GB of RAM in private bytes, too; probably something storing a lot of data (I blame Resharper).

Twilight is best pony.

A COMPROMISE!

[patio]

Useless oversized image...

Carry on however.

[BC_Programmer]

Useless oversized image...

Carry on however.

I could have put mine in a img tag as well. 2880x1800 just seemed a bit much for that.

[patio]

 

[Derpy Hooves]

Man, guess I gotta do some more reading on the Windows Kernel and memory management. I'll probably get Process Viewer, as well; seems like a handy little tool.

A COMPROMISE!

Hah, very nice. Weird thing is, I think I downloaded your Luna Redux one some time back...I'll have to go through my backgrounds folder. I'm following now though.

Useless oversized image...

Carry on however.

Yeah...they only allow BBC code for images, which cannot resize images like the HTML IMG tag, and it's not my picture...couldn't be bothered to download it, resize it, and upload it some where just to use it once here.

[Derpy Hooves]

Man, guess I gotta do some more reading on the Windows Kernel and memory management. I'll probably get Process Viewer, as well; seems like a handy little tool.
Hah, very nice. Weird thing is, I think I downloaded your Luna Redux one some time back...I'll have to go through my backgrounds folder. I'm following now though.Yeah...they only allow BBC code for images, which cannot resize images like the HTML IMG tag, and it's not my picture...couldn't be bothered to download it, resize it, and upload it some where just to use it once here.

I knew I was forgetting something.  Thanks for taking the time to explain some of this stuff!

[BC_Programmer]

I knew I was forgetting something.  Thanks for taking the time to explain some of this stuff!

You're welcome.

Man, guess I gotta do some more reading on the Windows Kernel and memory management. I'll probably get Process Viewer, as well; seems like a handy little tool.

Process Explorer. Not trying to be pedantic, just that there is a Process Viewer program too, but it's quite limited in it's capabilities.

I think I downloaded your Luna Redux one some time back...

That's one of my favourites out of the crapton I've made so far.

Carry on however.

Quite. We have continued on the discussion that revolves around our preference regarding Neotenous multi-hued sapient female horses, unicorns and pegasi  suffering from dwarfism, mixed most oddly with discussion about various lower-level windows semantics and various useful utilities that can be used to view such things.

Sort of like that time I explained the concepts of Object Oriented Programming using character references to cartooned equines. You know, the base class cEarthPony is specialized into both cUnicorn and cPegasus classes; which have composite cHorn and cWing aggregate classes respectively; cAlicorn naturally uses multiple derivation to be both a Unicorn and  Pegasus, and having the composite members of both. This introduces something a problem since there could be some vtable confusion as the Alicorn class now has two copies of the virtual dispatch table from the base cEarthPony class, since both the cPegasus and cUnicorn classes hold a reference to the base classes virtual dispatch table, as well as holding duplicate member variables for each. In this case, the cAlicorn class inherits the indirect base class cEarthPony once through the cPegasus class and once through the Unicorn class. This can be ambiguous because two subobjects of the cEarthPony class exist and both are accessible from the cAlicorn class; meaning that the actual virtual dispatch table that is acquired can depend on the type of the variable being used to access it. For C++ (which is the only language in common use that supports multiple inheritance) the way this is mitigated is through the concept of a virtual base class. but this needs to be done with the cUnicorn and cPegasus classes:

Code: [Select]

class cEarthPony { /* ...stuff... eye color, mane and tail color, etc */ };
class cPegasus : virtual public cEarthPony { /* ...aggregate wing composites, stuff like wing power, etc. */ };
class cUnicorn : virtual public cEarthPony { /* ...Unicorn specific stuff, Horn aggregate, magic aura colour, etc. */ };
class cAlicorn : public cPegasus, public cUnicorn { /* ... Alicorn specific stuff, like whether they have a crown or not.*/ };
this will ensure that the Alicorn only has one copy of the inherited members from the cEarthPony base class.

Naturally how some characters fit into this heirarchy raises a bit of a challenge, particularly Discord, but it's no worse than the common "Animal Kingdom" example that most tutorials use. And it's far less boring for those familiar with the subject.