The win32 installer seems to be using a lot of memory just to display the setup options. If you just start the installer the mozilla-win32-installer.exe uses 14.972 K on my Win2000 machine, which seems like a lot compared to other installers. Anything that can be done?
If we're using 14Mb before even launching XPCOM we could be in trouble. There are tons of 4K buffers everywhere which could be easily chopped way down. Not committing to fix, but perhaps worth looking at so throwing into the nsbeta1 pile for a more detailed look.
Just starting todays installer (mozilla-win32-installer.exe) 20010103 so that the installer stands at the Welcome screen, shows up as 16.148 KB Memory usage in Windows 2000 Task Manager.
Moz 0.8 tasks
Target Milestone: --- → mozilla0.8
I'm not sure how you're getting the 14.972K and 16.148K under NT2k. Under NT2000's task manager, I get 2.124K (build 01/15/01) and 1.828K (build 01/30/01) for SETUP.exe Under NT4's task manager, I get 2.536K (build 01/15/01) and 2.300K (build 01/30/01) for SETUP.exe All memory figures were determined at the Welcome screen.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
Ok here's the deal. I'm not talking about the setup.exe. I'm talking about the mozilla-win32-installer.exe Starting mozilla-win32-installer.exe shows me 16.148 KB BUT if I first do "-u" and the launch setup.exe it shows me 2.124K
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
We're past time to cut these low priority bugs from mozilla0.8. Please update these bugs today.
I found the problem. There are two things happening: 1) memory leak in nsinstall.cpp itself (which can easily be fixed) 2) memory usage (not leak) from a windows specific api that we cannot release, but that the api itself releases just prior to the app exiting (thus not a memory leak). Essentially, I can bring down the memory usage down to as low as 7-8mb for now. Patch coming up.
r=dveditz This patch fixes the leak but not the windows-specific lame resource handling. They put explicit calls to free specific kinds of resources (bitmaps, cursors, etc.) so they recognized the problem, but nothing for a generic user-defined resource such as we're using.
I suppose one option might be to have nsinstall launch setup.exe and then not wait for it to finish up. We'd have a cleanup problem though, which could be partially addressed by passing flags and/or paths into setup.exe when it was supposed to do the cleanup. But we wouldn't be able to get rid of setup.exe itself
I'd rather not leave setup.exe laying around. Another alternative is to use infoseek's code for self-extracting .exes. This path would also enable the installer to be built under Win9x as well as NT. But this is a different bug. seeking sr= now.
Status: REOPENED → ASSIGNED
patch checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
The memory usage after starting mozilla-win32-installer.exe is now down to: 10.708 KB That's: 8.560 KB for mozilla-win32-installer.exe 2.148 KB for setup.exe Much better... BTW: Why does mozilla-win32-installer.exe still need to live as a process when setup.exe is lauched????
Status: RESOLVED → VERIFIED
it needs to wait for setup.exe to exit in order to clean up 2 things: 1) TEMP\ns_temp\xpcom.ns - because xpcom does not unload all dlls it loads; ref counting is messed up. Since setup.exe is the main app, when it exits, all dlls loaded by it will be unloaded. 2) TEMP\ns_temp\setup.exe - because it can't delete itself while it's still running.
You need to log in before you can comment on or make changes to this bug.