Did you check the allocated memory in some operating system tool (like the Windows task manager) or in a Java profiler, like jvisualvm? I'm asking because after closing a Log window or closing a repository *and* invoking the garbage collector, the heap size should definitely go down (I've just verified both). This still does not mean that the garbage collector will actually release physical memory back to the system. The behavior of the garbage collector depends on the operation system, too. Thus, more details, including VM telemetries like the one produced by jvisualvm would be helpful.

Sorry, not sure what happened to my reply: I can reproduce the slowness and there are some promising ideas to make .gitignore processing faster which we are investigating.

Version 17.1 comes with an optional compact display: Changes|Compact Change Display

This "building" thing is what frightens me, as I guess it will require an appropriate build environment. But: you could send a complete directory listing (dir /b /s) and let me know the exact SHA of your HEAD. Then I'll be able to reproduce your state.

Can you please provide an entire repository, including working tree and ignored files to reproduce the problem? I guess a DropBox upload will be helpful.

It's probably possibly, but I guess some optimizations will be needed here. I have to profile this in more detail, what may take a while. What you may try: if there is a certain directory which contains most of the output files, you may ignore this explicitly in .git/info/excludes.

Sorry, the help was actually not clear about it -- I have changed that now.

Regarding the performance problem, the thread dumps confirm that most of the time is spent in Ignore-processing code. This fits to the 60000 ignored files you have mentioned. Ignore-processing will be slow if many files have been checked against the .gitignore patterns. For example: having all 60000 files in a directory (and sub-directories) ".out" and ignoring "out" or "out/", this will be fast, but ignoring "out/*.txt" or even "out/*" will be slow because SmartGit will have to check every out/* file against the pattern.

I guess you will see fast refreshing if temporarily removing all ignored files or adjusting the .gitignore as outlined above?

Unfortunately the dumps did not cover the problem: you have to invoke Create Periodical Thread Dumps before opening/closing the repository. Btw, how many (tracked) files does the repository contain? Can you also provide a clone URL, so I can see how long it takes for me?

Could it be due to a cold file system cache? If closing and reopening the repository again, does it become faster? Please also generate periodical thread dumps during closing and reopening a few time:

http://www.syntevo.com/doc/display/SG/Periodical+Thread+Dumps

Please give 17.1 RC a try and let me known whether this works better for you.