This question is locked. New answers and comments are not allowed.
Hi
I was just testing the EQUATEC PROFILER product, because of a strange performance issue in an app. // background:
I designed a custom tool for VisuaLStudio which compiles a text file and generates C# code, which is used internally and attached to the project.
This tool is registered as a COM object and exposed as a DLL which must be copied to the appropriate directory and registered within VS standards, all this have been done ok!
The real problem occurs when my custom tool is run fron within the visual studio, it works well but suffers a severe performance penalty, while lasting 2 seconds running from a command prompt, the SAME application doing the SAME job, took >2 minutes running from inside visual studio! (but everything worked fine, while the processor went into 100%cpu usage.. during the whole 2 minutes..)
When I debug the application, from within VStudio, the app delays also 2 minutes, while running as command prompt, it takes 2 seconds, 60x longer?
How can I make to use the profiler emulating the guts of the COM object or the VS environment
thank you after all, best!
andres
dasd
I was just testing the EQUATEC PROFILER product, because of a strange performance issue in an app. // background:
I designed a custom tool for VisuaLStudio which compiles a text file and generates C# code, which is used internally and attached to the project.
This tool is registered as a COM object and exposed as a DLL which must be copied to the appropriate directory and registered within VS standards, all this have been done ok!
The real problem occurs when my custom tool is run fron within the visual studio, it works well but suffers a severe performance penalty, while lasting 2 seconds running from a command prompt, the SAME application doing the SAME job, took >2 minutes running from inside visual studio! (but everything worked fine, while the processor went into 100%cpu usage.. during the whole 2 minutes..)
When I debug the application, from within VStudio, the app delays also 2 minutes, while running as command prompt, it takes 2 seconds, 60x longer?
How can I make to use the profiler emulating the guts of the COM object or the VS environment
thank you after all, best!
andres
dasd
4 Answers, 1 is accepted
0
Hi Andres,
What you're after is surely possible by using EQATEC Profiler. I have a link here to a previous question which is very similar to your scenario with respect to how to approach it. That question is about profiling unit tests, but profiling your COM-exposed DLL can use the same approach.
See http://eqatec.zendesk.com/entries/22863258-Profiling-unit-tests
60 times in execution difference is quite much. One thing that pops to mind is: could it be that the generated C# runs differently from command-line vs within VS? I mean, maybe it actually doesn't do the same thing after all? Just a thought.
Regards,
Richard
Telerik
What you're after is surely possible by using EQATEC Profiler. I have a link here to a previous question which is very similar to your scenario with respect to how to approach it. That question is about profiling unit tests, but profiling your COM-exposed DLL can use the same approach.
See http://eqatec.zendesk.com/entries/22863258-Profiling-unit-tests
60 times in execution difference is quite much. One thing that pops to mind is: could it be that the generated C# runs differently from command-line vs within VS? I mean, maybe it actually doesn't do the same thing after all? Just a thought.
Regards,
Richard
Telerik
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
0
Andres
Top achievements
Rank 1
Rank 1
answered on 25 Jun 2013, 03:09 PM
Hi there..
Richard, thanks, read the post but did not help.
I am not using unit-testing, the system I use is rather simple, uses lots of memory resources and recursive calls, it is a GLR compiler-compiler
The problem happens while using w7x64 4Gbram and E5300 2.8Ghz dual i86 cpu, I still have 2Gb free at all times!
While running as command-line the system dies the job in under 2 seconds, under the VS2008 environment I use the same DLL tied with a single command line thread, which includes the library and calls the same procedure.. the delay is over 2 - 3 minutes! (but strangely while running under VS the (one) CPU goes also 100% usage), same as under command line, but it does the same work (ouput compiled data is byte-to-byte) equal.
cannot understand!
as EQUATEQ runs internally, I dont know how to force it to run under VS as a COM object, may be processing the DLL and running it manually, but the VS needs a REGASM commadn to register the DLL adn the COM objects are tricky, also the system might check it the DLL is not tampered by assuring it is signed! - so it might fail!
any other clue?
thanks
Richard, thanks, read the post but did not help.
I am not using unit-testing, the system I use is rather simple, uses lots of memory resources and recursive calls, it is a GLR compiler-compiler
The problem happens while using w7x64 4Gbram and E5300 2.8Ghz dual i86 cpu, I still have 2Gb free at all times!
While running as command-line the system dies the job in under 2 seconds, under the VS2008 environment I use the same DLL tied with a single command line thread, which includes the library and calls the same procedure.. the delay is over 2 - 3 minutes! (but strangely while running under VS the (one) CPU goes also 100% usage), same as under command line, but it does the same work (ouput compiled data is byte-to-byte) equal.
cannot understand!
as EQUATEQ runs internally, I dont know how to force it to run under VS as a COM object, may be processing the DLL and running it manually, but the VS needs a REGASM commadn to register the DLL adn the COM objects are tricky, also the system might check it the DLL is not tampered by assuring it is signed! - so it might fail!
any other clue?
thanks
0
Richard Flamsholt
Top achievements
Rank 2
Rank 2
answered on 26 Jun 2013, 08:57 AM
Hi Andres,
The post I referred to was about profiling unit-tests, but what I meant was that the approach for doing so was quite similar to what you could use. Here is how:
You have a dll X with code that you would want to profile.
The way to do this is simply to instrument ("Build") that dll with the profiler and then make sure to have THAT dll X2 be executed instead of the original X. (The profiler can re-sign dlls so that's not a problem). This may involve manually copying the dll to somewhere else, regasm it or whatever. The profiler doesn't know and it doesn't care. In any case, you just have to make sure that X2 is being used instead of the original X in your VS scenario. Are you with me so far? The profiler builds X2. You must make sure X2 is the one being executed, not X.
When any code in X2 executes then the added timing-code will kick in and start profiling the methods. I doesn't matter how X2 gets executed, not one bit: as soon as code in it DOES get executed, it will start recording timing data. Yes, it is X2 itself that does the profiling of itself, not the profiler - it's job is just to build the instrumented X2 version and later display the results.
Now the tricky part is how to get that data OUT of X2. The easiest way is to have the profiler running at the same machine, because when X2 starts profiling itself it will attempt to connect to a profiler via a socket connection. When that happens you will see a "X was started" notice in the profiler and THEN you can extract profiling information: clean the counters and take a snapshot.
Therefore: if you can just somehow make sure that the instrumented version of your dll is being executed, then profiling will always work.
best regards,
Richard Flamsholt, Telerik
The post I referred to was about profiling unit-tests, but what I meant was that the approach for doing so was quite similar to what you could use. Here is how:
You have a dll X with code that you would want to profile.
The way to do this is simply to instrument ("Build") that dll with the profiler and then make sure to have THAT dll X2 be executed instead of the original X. (The profiler can re-sign dlls so that's not a problem). This may involve manually copying the dll to somewhere else, regasm it or whatever. The profiler doesn't know and it doesn't care. In any case, you just have to make sure that X2 is being used instead of the original X in your VS scenario. Are you with me so far? The profiler builds X2. You must make sure X2 is the one being executed, not X.
When any code in X2 executes then the added timing-code will kick in and start profiling the methods. I doesn't matter how X2 gets executed, not one bit: as soon as code in it DOES get executed, it will start recording timing data. Yes, it is X2 itself that does the profiling of itself, not the profiler - it's job is just to build the instrumented X2 version and later display the results.
Now the tricky part is how to get that data OUT of X2. The easiest way is to have the profiler running at the same machine, because when X2 starts profiling itself it will attempt to connect to a profiler via a socket connection. When that happens you will see a "X was started" notice in the profiler and THEN you can extract profiling information: clean the counters and take a snapshot.
Therefore: if you can just somehow make sure that the instrumented version of your dll is being executed, then profiling will always work.
best regards,
Richard Flamsholt, Telerik
0
Hi Andres,
The post I referred to was about profiling unit-tests, but what I meant was that the approach for doing so was quite similar to what you could use. Here is how:
You have a dll X with code that you would want to profile.
The way to do this is simply to instrument ("Build") that dll with the profiler and then make sure to have that dll X2 be executed instead of the original X. (The profiler can re-sign dlls so that's not a problem). This may involve manually copying the dll to somewhere else, regasm it or whatever. The profiler doesn't know and it doesn't care. In any case, you just have to make sure that X2 is being used instead of the original X in your VS scenario. Are you with me so far? The profiler builds X2. You must make sure X2 is the one being executed, not X.
When any code in X2 executes then the added timing-code will kick in and start profiling the methods. I doesn't matter how X2 gets executed, not one bit: as soon as code in it does get executed, it will start recording timing data. Yes, it is X2 itself that does the profiling of itself, not the profiler - it's job is just to build the instrumented X2 version and later display the results.
Now the tricky part is how to get that data out of X2. The easiest way is to have the profiler running at the same machine, because when X2 starts profiling itself it will attempt to connect to a profiler via a socket connection. When that happens you will see a "X was started" notice in the profiler and then you can extract profiling information: clean the counters and take a snapshot.
Therefore: if you can just somehow make sure that the instrumented version of your dll is being executed, then profiling will always work.
I hope this works. If not then please write again.
Regards,
Richard
Telerik
The post I referred to was about profiling unit-tests, but what I meant was that the approach for doing so was quite similar to what you could use. Here is how:
You have a dll X with code that you would want to profile.
The way to do this is simply to instrument ("Build") that dll with the profiler and then make sure to have that dll X2 be executed instead of the original X. (The profiler can re-sign dlls so that's not a problem). This may involve manually copying the dll to somewhere else, regasm it or whatever. The profiler doesn't know and it doesn't care. In any case, you just have to make sure that X2 is being used instead of the original X in your VS scenario. Are you with me so far? The profiler builds X2. You must make sure X2 is the one being executed, not X.
When any code in X2 executes then the added timing-code will kick in and start profiling the methods. I doesn't matter how X2 gets executed, not one bit: as soon as code in it does get executed, it will start recording timing data. Yes, it is X2 itself that does the profiling of itself, not the profiler - it's job is just to build the instrumented X2 version and later display the results.
Now the tricky part is how to get that data out of X2. The easiest way is to have the profiler running at the same machine, because when X2 starts profiling itself it will attempt to connect to a profiler via a socket connection. When that happens you will see a "X was started" notice in the profiler and then you can extract profiling information: clean the counters and take a snapshot.
Therefore: if you can just somehow make sure that the instrumented version of your dll is being executed, then profiling will always work.
I hope this works. If not then please write again.
Regards,
Richard
Telerik