Plannedscape Postings

Image

Memory Hogs (Part 1)
Problem Child Example Of A Memory Leak Website

Posted by Charlie Recksieck on 2022-03-03
Have you noticed that your computer gets slow after it's been on for a long time? Or particularly slow after visiting certain websites or using certain programs?

Or perhaps you have a website or app of your own where speed and performance have become a known issue.

If so, then let's get into the idea of "memory hogs".


What's A Memory Hog

Any program or app that uses an excessive amount of a computer's RAM memory. Very often it's not a matter of bad design that it uses so much processing power to do its tasks; rather, it's that it does a sloppy job of using programming objects (think of them as snippets of code to be insanely simple) but not doing a proper job of closing them from memory when done. As a result, it occupies the same RAM even after it's done.

1 or 2 bad instances of "memory leaks" like this are tolerable but scaled up in a large app (or website) while there are hundreds of services running on your computer, it gets bad. Bad enough where it's time to reboot the computer.


Why Does This Happen

It's a fairly complex question, but I'll oversimplify the answer by saying it happens most when code creates an instance of an object (here's a rabbit-hole of a definition) but the code doesn't actually close or "dispose" of the object so it no longer occupies RAM memory after the code has done what it needs to do.

Each programming code has its own default conventions and policies about the "scope" and "persistence" of objects, which regularly prevents sloppy programmers from overusing memory. But there are plenty of instances when objects must be created in a way where they stay in memory after all the code has been run.

And in websites, the more code-ish the page is - when they use JavaScript, PHP, Python beyond just HTML - the more objects are used, and the higher risk that they will chew up valuable RAM.

Modern computers keep getting created with more and more RAM, so they are better at dealing with having 20 website tabs and 10 different apps running in the foreground in addition to the huge amount of services that now run in the background on your computer. In a way, this allows us to get into bad habits as computer users keeping a silly number of things open ... and allows bad programming to not slow people down too much. But that doesn't make it right.


What Apps Cause This

I've been developing third-party apps for AutoCAD and the electric utility industry since the 20th century. Ouch. AutoCAD itself is extremely complex and known as a bit of a memory hog to begin with - meaning that it takes dozens of processes running on a computer to just run the one AutoCAD app. In third-party apps and code that we've been involved with, we've become hyperconscious to make sure to dispose of the complex code objects in AutoCAD; especially since one object may have 10 dependencies so it requires 10 other .DLLs running to support it. As long as a process is running, objects occupy X amount of space.

AutoCAD is an extreme example of a big hog. Where things get chipped away are at the website level. As we mentioned above, if the page is doing a lot of complex JavaScript but doesn't get rid of its objects after using them, then as long as that tab is open in a browser, things are going to slow down little by little. (To a programming audience I would say that 90% of this happens when coders get sloppy and create objects in a global space for easy access. Enough about that for this article.)

For instance, on a webpage you could have a global variable like this:

function StartUp() {
this.variableMessage = "something accessible in all code";
}


This isn't too damaging because this is just a simple string variable (holding a quote of a few words), but when there are more complex types that require whole processes to be created, then things get hairy.


Part 2 will cover a particularly egregious example of a memory hog website and will be available here starting March 10, 2022.



Click here to read Part 1