I work with Accounting Software. The program is massive in size. Currently it has 332 windows and 38 modules. Im looking for a way to split the program in to multiple executables, or some other way that would reduce the memory usage. I would rather not have multiple executables. Everything is built right into the one program, packaged up as one executable. What is the best way to reduce the memory usage without making multiple executables? I know this is bit vague and Ill answer any questions. Thanks for the help.
Is it built as 64 bit or 32 bit?
Built as 32 bit
I think that question suggests a potential solution too. 
64 bit would alleviate some pressure.
Does it have to stay as 32 bit?
If so there’s a limit to what you’ll be able to do
- turn OFF implicit instance for all windows and explicitly instantiate them and explicitly nil them when done with them
- make sure you’re not holding on to references to objects you no longer need in memory
Hm…I’ve worked on projects with those numbers of Windows. I wouldn’t think you’d have much problem. It might be indicative of a larger overall problem.
How do you know you’re running out of memory? And does the amount of memory used go up in a steady drip or as windows are opened? Does it ever regain memory?
Do you have a window strategy where you’re closing windows or just making them invisible? Are you pre-loading objects that you might want to delay until actually used?
You could attempt to go to 64-bit but if you have a memory leak, or circular references, you’re only delaying the inevitable as you’ll still eventually use up all RAM on the machine (even if Xojo can access more).
While you said you didn’t want multiple executables, and you cannot find another viable (and future proof solution)… try dividing the logic into major actions (for example Acct-Payable, Acct-Reci etc)… so that the state of the data remain independant of the application. You end up with an Accounting SYSTEM made of of functionally independent Accounting Programs
Or … what about turning it into a web app for the primary logic elements and let the browser do the work on the local desktop? This means one beefy machine in the back room and Kindle Fire HDs for the staff.
[quote=417093:@Jason Parsley]64 bit would alleviate some pressure.
Does it have to stay as 32 bit?
If so there’s a limit to what you’ll be able to do
- turn OFF implicit instance for all windows and explicitly instantiate them and explicitly nil them when done with them
- make sure you’re not holding on to references to objects you no longer need in memory[/quote]
It does have to stay 32 bit. Some of the computers this program runs on are very old. Its accounting software for Schools and some of the schools don’t have the budget to give their clerks an updated computer. So right now it still has to be able to run on XP as well as Windows 10. Will have to read more the two things you suggested and I will try that.
[quote=417096:@Bob Keeney]Hm…I’ve worked on projects with those numbers of Windows. I wouldn’t think you’d have much problem. It might be indicative of a larger overall problem.
How do you know you’re running out of memory? And does the amount of memory used go up in a steady drip or as windows are opened? Does it ever regain memory?
Do you have a window strategy where you’re closing windows or just making them invisible? Are you pre-loading objects that you might want to delay until actually used?
You could attempt to go to 64-bit but if you have a memory leak, or circular references, you’re only delaying the inevitable as you’ll still eventually use up all RAM on the machine (even if Xojo can access more).[/quote]
Ive put in a window to tell me the amount of memory being used. As I navigate through the windows, the memory usage goes up and never gets released. It never regains memory and eventually crashes the program. I can’t go to 64 bit because the program is running on school districts throughout my state. Some of the computers that the clerks are given are still running on xp.
Oh my. So on top of 32-bit you’re running an older version of Xojo too since 2017 R2(?) and better builds no longer work on XP.
Okay. So do you ever truly close windows or just hide them? Are you using any data classes like ActiveRecord or using straight database code?
If you could share a typical window that might be enough for us to tell you something. Or allow us to come up with more questions.
If you are in desperation mode it might make sense to get one of the consultants on board for a review. Xojo: Find a Developer. Full disclosure: I monitor this list.
I was thinking more of moving the common methods out of of the program and creating libraries that can be called when they are needed. I haven’t done much with libraries so I’m not sure something like that would work. There are just so many little methods are are used throughout the program everywhere. Moving them out should reduce them memory usage I would guess. Everything is just built into this one big file right now.
Moving commonly used code into a module etc won’t have much, if any, impact to reduce memory usage (unless you have many many copies of the same code all over the place).
I’ve done accounting applications in Xojo both in Desktop and Web. They’re huge monsters to say the least and we’ve never had the memory issues you’re having. You’re doing something that’s not allowing the memory to be released automagically. I’m not sure anyone here is going to be able to diagnose the issue without seeing more code.
[quote=417110:@Bob Keeney]Oh my. So on top of 32-bit you’re running an older version of Xojo too since 2017 R2(?) and better builds no longer work on XP.
Okay. So do you ever truly close windows or just hide them? Are you using any data classes like ActiveRecord or using straight database code?
If you could share a typical window that might be enough for us to tell you something. Or allow us to come up with more questions.
If you are in desperation mode it might make sense to get one of the consultants on board for a review. https://xojo.com/resources/consultants.php. Full disclosure: I monitor this list.[/quote]
Not even Xojo. Still running on Real Studio 2012. Closing the windows when finishing with them. No data classes or any kind of class except for some for download and upload CURLS from MBS, using straight database code. Heres a link to a window that you can open and take a look: https://drive.google.com/file/d/1rbFcSaiHdpgiOKDWfW8ytMT-vDgWLeiC/view?usp=sharing
Heres a link to download a window to get an idea of what’s going on. Mind you this programming goes way back before me. This is just an example of what’s going on throughout the program. https://drive.google.com/file/d/1rbFcSaiHdpgiOKDWfW8ytMT-vDgWLeiC/view?usp=sharing
Are these windows set with “Implicit instance = true”? If so, closing them will make them not visible but not free up any memory they use as the code that creates the implicit instance hangs on to it. If you turn that off on all windows and then run you’ll get some idea of how reliant the program is on implicit instances and also where you need to fix things.
But turning it off and then creating and closing and nilling the references would free up memory - how much I don’t know.
You could probably update to 2015r2.4 if all clients are using XP SP 2.
Not seeing anything in a cursory glance that’s worrisome. FWIW I strong advice against 700 line methods with nest levels of 10 deep. They are problematic to debug.
Jason brought it up earlier but I think ImplicitInstance on Windows is evil. https://www.bkeeneybriefs.com/2016/01/implicitinstance-is-evil/ I’d do this window by window and see where the compiler complains. ImplicitInstance can cause very subtle bugs.
I see a few places in your code where you’re using NameOfTheWindow.SomeProperty rather than Self.SomeProperty and that bugs me. It’s probably nothing but there’s nothing I see in this window that would create a memory leak.
Besides XP is there any reason why you couldn’t upgrade to a newer version of Xojo? Other than money? I mean we’re putting in a lot of time for a 6 year old development tool that I haven’t opened in at least a year.
[quote=417121:@Jason Parsley]Are these windows set with “Implicit instance = true”? If so, closing them will make them not visible but not free up any memory they use as the code that creates the implicit instance hangs on to it. If you turn that off on all windows and then run you’ll get some idea of how reliant the program is on implicit instances and also where you need to fix things.
But turning it off and then creating and closing and nilling the references would free up memory - how much I don’t know.
You could probably update to 2015r2.4 if all clients are using XP SP 2.[/quote]
I went through 10 windows and implicit instance is turned on for them all. Does that mean everything being created every time a windows runs is not being released back to memory? Even when I call the close? That would make sense because that what it looks like when Im watching the memory usage for the program go up and up until crash.
[quote=417124:@Bob Keeney]Not seeing anything in a cursory glance that’s worrisome. FWIW I strong advice against 700 line methods with nest levels of 10 deep. They are problematic to debug.
Jason brought it up earlier but I think ImplicitInstance on Windows is evil. https://www.bkeeneybriefs.com/2016/01/implicitinstance-is-evil/ I’d do this window by window and see where the compiler complains. ImplicitInstance can cause very subtle bugs.
I see a few places in your code where you’re using NameOfTheWindow.SomeProperty rather than Self.SomeProperty and that bugs me. It’s probably nothing but there’s nothing I see in this window that would create a memory leak.
Besides XP is there any reason why you couldn’t upgrade to a newer version of Xojo? Other than money? I mean we’re putting in a lot of time for a 6 year old development tool that I haven’t opened in at least a year.[/quote]
I’ll read more on the implicit instance and see if that’s what’s causing my problems. Thanks for taking a look. As far as upgrading, all of the newer projects are in Xojo. We have a Xojo pro license. This program being discussed is just so massive that It takes a lot of programming to get it to work with Xojo. The biggest is SQL transactions being left open by default and it would take some time to convert it so that it works correctly. We are always talking about making the switch and eventually we will but right now we’re stuck.