Search Home Members Contacts
About Us
Products
Downloads
Community
Support
Pages: [1]
  Print  
Author Topic: Free .NET profiler  (Read 2087 times)
Hypnotron
Customers
Community Member
*****
Posts: 1046


« on: February 14, 2009, 06:48:31 PM »

http://www.eqatec.com/tools/profiler

bsd license
http://www.eqatec.com/tools/profiler/license

says it works with managed c++, c#, vb.net, j#, F# and .net 2.0 to 3.5 and compact framework but NOT 1.1.  Hardly anyone using 1.1 anymore anyway...

----
UPDATE: There is a nasty catch apparently...


no thanks.
« Last Edit: February 14, 2009, 07:13:13 PM by Hypnotron » Logged
jviper
Community Member
*
Posts: 2130

Discipline in training


« Reply #1 on: February 15, 2009, 10:04:37 AM »

Weird. The physics engine runs really slow when I run this. Any idea?
Logged

JAbstract.....Don't just imagine, make it happen!
Hypnotron
Customers
Community Member
*****
Posts: 1046


« Reply #2 on: February 15, 2009, 04:01:12 PM »

No idea.  In general, profiling adds some performance overhead but that varies from profiler to profiler.  But the idea is to deal with the relative results from the profile run to determine what parts of your code are hurting performance the most. 
Logged
ricflams
Community Member
*
Posts: 2


« Reply #3 on: February 18, 2009, 09:18:21 AM »

UPDATE: There is a nasty catch apparently...
no thanks.

I wrote the text in the screenshot (and most of the profiler itself) and had a really hard time making it accurate and brief and non-scary. Guess I failed :-) Reading your reaction certainly makes it clear that it needs to be improved.

What it means is simply that there's a feature to let the profiler communicate with your profiled program. It does so by using TCP/sockets, just like some debuggers do to communicate with the program being debugged (if debugging remotely or on a mobile device over activesync etc). There's nothing dubious about that - if two programs need to communicate they have to do it some way or another :-) and we simply chose to use sockets. But: the Windows firewall will not allow socket-communication without raising a notice even when the two programs are started by you and running on the same PC. How annoying. That's why we added this "add an exception rule automatically"-option.

We'll try to improve the explanation, maybe by using a picture. I know that many users (myself, for instance) look at long elaborate texts and simply read "blah blah blah, okay I don't care, now where do I press next?" in their head. In this case many might just notice the firewall-word and be turned off immediately, reading "blah blah firewall ... uh-oh, what!? probably some trojan stuff, so goodbye".

cheers,
Richard Flamsholt,
EQATEC
Logged
ricflams
Community Member
*
Posts: 2


« Reply #4 on: February 18, 2009, 09:31:17 AM »

Weird. The physics engine runs really slow when I run this. Any idea?

The profiler's timing-code adds a lot of overhead to each method. For many programs this only mean, say, a 25% slowdown but especially for computational-intensive programs that use lots of small methods it can really be a killer, making the program run many times slower.

Unfortunately you cannot easily turn profiling off for just a few methods that may cause 90% of the  overhead - you can only turn profiling on/off on assembly-level, ie exclude an entire DLL or EXE from being profiled. Doing that would be my best suggestion.

(I said "easily", because you can in fact decorate individual classes or methods with profiler attributes that will exclude them from being profiled, but you will have to do it in the engine's source and recompile it afterwards. It's certainly possible, but not simply "click-and-go"-easy).

Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.3 | SMF © 2006-2007, Simple Machines LLC
Seo4Smf v0.2 © Webmaster's Talks