VS 2008 - GC.Collect: Memory Vs Performance?

I have an application (i've been working on for a long time) that has many tabs and controls and quite a few components And a good deal of design code. And a list box that has around 100k items (i had to put a loader to pass the 3-4 seconds while its loading to prevent it from not-responding)I had a few Gc.collect calls in specific places (mostly after many items are added or removed). When my application loads, i call GC.collect only once at the end of the load. The program consumes around 35K memory by the time its loaded. However, i decided to mess around abit (don't worry i made backups)First i started putting gc.collect in some random places, and to my surprise the memory upon loading was observably decreasing. Then I went ahead and put a macro that puts GC.Collect before every End Sub, Exit Function, Exit Sub, and Return value, there is. Basically every block in my application had atleat one GC.Collect.
I fixed some 6 or 7 silly replace errors and compiled. When the program launched, the memory used at the end of launch was 21K!

At first glance that seemed great, but then i realized switching between tabs was VERY glitchy. and adding new lists took around 10x more time than usual (the loader stayed on for around 20 seconds!) And even though the memory looked good, the program was useless like this.Then i decided to mess around differently. I removed GC.Collect from the entire solution. It was no longer called even once.At first glance, when i launched the app it consumed just under 60K memory. That seemed terrible. However i realized something: even though my program in that state showed on taskmanager that it was consuming alot more memory than usual, it seemed like it was lighter than ever! Switching tabs was faster than before, especially every time i go to the tab that has the listbox control with 100k items. Loading items took around 3-4 seconds, but there was no stutter when the list finished loading whereas before it had an evident 0.3s stutter after the items were added.

This was all surprising to me because i thought GC.Collect was first of all, something that it doesnt matter where or how many times you call it. I thought it was just something that should be called at the end of work and i didnt think it would matter if it was called during work.Second of all, i thought GC.Collect only affected resources that are inaccessible, or resources my program is done with. How come the application feels faster when i don't call it?Third of all, i thought the VB CLR does most of the memory cleaning for me, and that GC.Collect was somewhat of a redundant command. It didn't seem so redundant to me at all considering the difference between using it heavily and not using it at all was around 38K in memory usage!

So i guess my questions are:
1) Do I need to call GC.Collect? WhereWhen do i call it?2) Why does calling it affect performance? And where does one draw the line between that memory stat on taskmanager and the program's performance?3) I also decided to run a small test. Why does a blank vb form application require 10K memory? How accurate is that stat shown on the task manager?