haacked / seegit

SeeGit - The Git Repository Visualizer
MIT License
508 stars 107 forks source link

The number of recursive calls diminished from num(commits) to num(branches) #57

Closed Therzok closed 11 years ago

Therzok commented 11 years ago

Still not good enough. We need something else to handle this.

Therzok commented 11 years ago

Didn't get to test enough to see if it fixes #56 since RAM is low on my laptop.

Therzok commented 11 years ago

It stopped at 2gb RAM usage and now it's rendering it.

Therzok commented 11 years ago

Note: This is not the most efficient method. I still think the reversed method using a Stack is better, but I'm thinking there is a way better way.

Note 2: Tried with List instead of queue, it proved to be slower. :P

haacked commented 11 years ago

I haven't had a chance to dig into this deeply, but I wonder if a tail call optimization would help. It's not supported by C# so it'd require us to use goto (blech).

Therzok commented 11 years ago

Yeah. Was thinking of goto as an alternative, but considered it ugly. This way doubles cpu time, probably because of the GC. I'll do tests with goto to see if it improves anything.

haacked commented 11 years ago

In this case, the goto is to workaround a missing feature so if it's well commented, I think it's fiiiiine. Assuming it actually helps. ;)

Therzok commented 11 years ago

I've got it running without recursivity. Now to solve the hanging.

haacked commented 11 years ago

Cool! Was it faster?

Therzok commented 11 years ago

28.40 cpu time for first run on recursive. 4.54 on 2nd.

New method is 27.92 for first run. 4.72 for 2nd.

I'll commit code, squash commits as soon as I find out why it hangs on repository graph setting.

Therzok commented 11 years ago

Also, do you use IRC? :P Any channel I can find out on?

Therzok commented 11 years ago

It's a rendering issue towards WPF. Since it seems to do the graph layout and print out execution time for SharpDevelop repository. Yet, it never gets past the RaisePropertyChanged on Graph.

Therzok commented 11 years ago

It has 9082 vertices. I guess it's a rendering issue more than a CPU one now.

Therzok commented 11 years ago

I'm finding CPU 'leaks'. As in same thing done twice for nothing. :P

Therzok commented 11 years ago

Should the rendering issue be caused by a bottleneck in GraphSharp?

haacked commented 11 years ago

Hi Therzok, I'm not on IRC. I tend to turn off all notifications when I'm in "work mode". :)

Should the rendering issue be caused by a bottleneck in GraphSharp?

I don't know. It's entirely possible. Are there upgrades available?

Therzok commented 11 years ago

Yeah, 1.0, but I can't patch it up from this workstation. I don't have NuGet installed.

haacked commented 11 years ago

Ok, I'll do that real quick and push to master. And maybe you can rebase your work off that. Sound good?

haacked commented 11 years ago

And WHY DON'T YOU HAVE NUGET INSTALLED!?!?!??! :stuck_out_tongue:

Therzok commented 11 years ago

Sure thing. I'm using a Visual Studio Express edition on this workstation. :D

haacked commented 11 years ago

Do you have VS2012 Express? NuGet comes with it. I wonder if we should update our solution.

Therzok commented 11 years ago

Ah, I'm still using 2010. As soon as I get home, I'll update to 2012.

haacked commented 11 years ago

For Visual Studio 2010, NuGet only works with Visual Web Developer (which is free). Stupid restrictions don't make it work in Visual C# Express.

Therzok commented 11 years ago

Ah, I see. Thanks for the info.

haacked commented 11 years ago

So I just checked and we have a private copy of GraphSharp etc. Not sure why I did that. Maybe there weren't NuGet packages when I started. I'll try installing them from NuGet and see what happens.

Therzok commented 11 years ago

Yeah, so this thing is not related to SeeGit anymore, but the way WPF can't receive the Graph binding.

Therzok commented 11 years ago

This is the most I can do. After RaisePropertyChanged(() => Graph); it just hangs. I left it open for an hour and it still didn't get changed. It could be a WPF thing.

Therzok commented 11 years ago

I think the only solution would be limiting the size of the repo graph.

jogibear9988 commented 11 years ago

Maybe it is possible to Virtualize the Graph?

But I think it is still a Problem then if you'd Zoom Out to far

Therzok commented 11 years ago

Adding a lazy load to the graph will not help solve this issue, especially if you zoom out.

WPF is at fault here. Phil, this calls for you! =D

Therzok commented 11 years ago

Any idea here, Phil? Stuck on this WPF stuff for a while and waiting for some insight.

haacked commented 11 years ago

Heh, sorry man. So busy. Should we try upgrading to WPF 4.5 and see if that helps? Do you think I should take this fix anyways even if it doesn't improve perf the way we hoped?

Therzok commented 11 years ago

It does increase depth for at least some values. I don't know, it's your call here.

haacked commented 11 years ago

If you give me a :thumbsup: I'll merge it. :smile:)

Therzok commented 11 years ago

Let's try it :+1: