49456 - memory use in installer is *very* high

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P4)

Description

[Henrik Gemal]

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?

Comment 1

[Daniel Veditz [:dveditz]]

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.

Comment 2

[Henrik Gemal]

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.

Comment 3

[Daniel Veditz [:dveditz]]

Moz 0.8 tasks

Comment 4

[Sean Su]

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.

Comment 5

[Henrik Gemal]

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

Comment 6

[Henrik Gemal]

Attachment: screenshot of installer and task manager

Comment 7

[selmer (gone)]

We're past time to cut these low priority bugs from mozilla0.8.  Please update
these bugs today. 

Comment 8

[Sean Su]

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.

Comment 9

[Sean Su]

Attachment: patch #1

Comment 10

[Daniel Veditz [:dveditz]]

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.

Comment 11

[Daniel Veditz [:dveditz]]

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

Comment 12

[Sean Su]

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.

Comment 13

[Scott MacGregor]

sr=mscott

Comment 14

[Sean Su]

patch checked in.

Comment 15

[Henrik Gemal]

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????

Comment 16

[Sean Su]

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.