Closed Therzok closed 11 years ago
Didn't get to test enough to see if it fixes #56 since RAM is low on my laptop.
It stopped at 2gb RAM usage and now it's rendering it.
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
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).
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.
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. ;)
I've got it running without recursivity. Now to solve the hanging.
Cool! Was it faster?
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.
Also, do you use IRC? :P Any channel I can find out on?
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.
It has 9082 vertices. I guess it's a rendering issue more than a CPU one now.
I'm finding CPU 'leaks'. As in same thing done twice for nothing. :P
Should the rendering issue be caused by a bottleneck in GraphSharp?
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?
Yeah, 1.0, but I can't patch it up from this workstation. I don't have NuGet installed.
Ok, I'll do that real quick and push to master. And maybe you can rebase your work off that. Sound good?
And WHY DON'T YOU HAVE NUGET INSTALLED!?!?!??! :stuck_out_tongue:
Sure thing. I'm using a Visual Studio Express edition on this workstation. :D
Do you have VS2012 Express? NuGet comes with it. I wonder if we should update our solution.
Ah, I'm still using 2010. As soon as I get home, I'll update to 2012.
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.
Ah, I see. Thanks for the info.
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.
Yeah, so this thing is not related to SeeGit anymore, but the way WPF can't receive the Graph binding.
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.
I think the only solution would be limiting the size of the repo graph.
Maybe it is possible to Virtualize the Graph?
But I think it is still a Problem then if you'd Zoom Out to far
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
Any idea here, Phil? Stuck on this WPF stuff for a while and waiting for some insight.
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?
It does increase depth for at least some values. I don't know, it's your call here.
If you give me a :thumbsup: I'll merge it. :smile:)
Let's try it :+1:
Still not good enough. We need something else to handle this.