Entries by Edgar Sanchez

I was on the road the last few days counseling our clients on how performance issues can be detected in .NET applications. Upon perusing my last entry once more, I realized that my account was not complete, since I haven't yet informed you about the new features SpeedTrace 3.3 is going to bring to the market soon. Therefore, I'd like to just provide you with a short outline of some of the coolest features this tool has.

SpeedTrace 3.3 features:

• Tracing of multiple processes:
  You can run several instances of SpeedTrace in parallel, so you can profile/trace different processes simultaneously in order to help you to focus on certain segments of your application at the same time.
  
• Call history scoping:
  SpeedTrace enables you to open partial traces just to see the callees of a given function by focusing exclusively on the calls made within a given segment.
  
• Generating trace output from a terminated process:
  An application that terminates unexpectedly may cause a real headache and waste a lot of time if you cannot analyze its cause properly. Due to SpeedTrace’s robust architecture, it yields reliable results thorough to the last drop even when your application crashes.
  
• Hotspot filter:
  Whenever you activate it, SpeedTrace will only display the nodes with own times higher than the specified threshold.
  
• Comparing profile results:
  It is important to know whether changes made within your code have a positive upshot or predominantly negative side effects. You can compare profile results with counterpoint method timings and allocation issues.
  
• Triggers: Specify the method that will start or stop the profiling process in order to analyze specific behavior within specified boundaries.
  
• Black box filter:
  3rd party components that cannot be improved always flood the analysis with irrelevant information. SpeedTrace, however, can encapsulate these components by just providing transitions for the ones you need.
  
• Data trace:
  SpeedTrace helps you to locate bugs (e.g. programming errors, deadlocks, missing or wrong version of DLL) easily, allowing you to examine the data flow channeled through the various functions.
  
• Code location in Microsoft Visual Studio:
  Whenever you find an issue, a quick tune of the code is required. You can always click on the Source view in SpeedTrace to locate your code in Visual Studio.
  

After several months of intense work, the development team of SpeedTrace is introducing a new version of SpeedTrace dot.NET Profiler and Tracer. Although it is not a release version, it is robust enough to prove its new capabilities. We have called it

SpeedTrace dot.NET Profiler and Tracer 3.3 Preview Beta

This version is running until the end of June, so start downloading and check out its new features and capabilities today!

If you have recently downloaded the other version of our .net profiler (3.2), you will be receiving an email with the direct link to our new version in no time. However, if you do not want to wait for this email, please click here and get SpeedTrace dot.NET Profiler and Tracer 3.3 Preview Beta now!

In order to have a better release, we would appreciate your feedback on suggested improvements. Please send us your comments.

In many msdn blogs I have noticed that people are trying to understand why certain dll's or function/methods show up in their performance analyses contrary to their wish after profiling their application with VS.

Usually, one can use a dot.net sampling profiler to drill down to the problem of an application. Yet having done that, what if the sampling data does not provide the relevant data and sufficient information? Well, for every question there is, of course, always an answer: a trace profiler can offer more and important detailed information, especially if your application works in a multithread environment. On the other hand, every solution also has its drawbacks, and this is no exception. Therefore, when you profile a huge application, you may find that you'll be flooded with information in a huge trace result, and your application's performance is liable to be sensitively impaired by the procedure on top of it.

However, the SpeedTrace dot.net profiler, finally offers you a way out of this dilemma! Thanks to its three-level filtering approach (illustration below), you will be able to avoid (and reduce to a minimum) the unnecessary information that normally holds you back when tracking down the essential performance issue. Besides, by thus streamlining its tracing and profiling capabilities it also prevents the impacts that normally occur to your applications' performance when you subject them to these kinds of procedures.

And this is how it works:

• The recording filter (only available in the Pro version) first collects all method calls and is apt to maximize trace speed, minimize resource usage (memory, time, power, etc.), and minimize the bulk of information
• The pre-processing filter (available in the Basic and Pro versions) then works on the traced calls and further minimizes resource usage and minimizes the information to what is relevant and sufficient
• The post-processing filter (available in the Basic and Pro versions) finally filters the pre-processed calls and minimizes the information to that which is quintessential, leaving you with a perfectly profiled and thoroughly useful account of your problem.

The bottom line of the story is:

The SpeedTrace filterering system is simply a tool you cannot do without when bug trapping your application!

As part of our strategy improvements we are currently looking for an independent sales representative for our SpeedTrace dot.net Profiler and Tracer in the USA.

Our sales representative for dot.NET applications will perform the following tasks:

• Contact (potential) clients/customers and work out the software requirements of their businesses
• Create customer interest in our company's IT products
• Keep customers informed on new product developments and IT innovation opportunities
• Hold presentations at IT conventions and expositions (e.g. lectures at conferences or .NET user group meetings)
• Provide after-sales support
• Participate in marketing (e.g. writing press releases, articles in US magazines, etc.) and client education activities
• Talk to IT engineers (analysts, designers, programmers)
• Perform continuous updates of own knowledge of .NET products
• Monthly marketing report of activities

Personal Requirements:

• Personable and assertive
• Good communication and presentation skills
• Perseverance
• Ability to understand clients' needs quickly
• Willingness to regularly update product knowledge
• Ability to master full scope product functionality and application opportunities
  
• Good customer service skills
• Thorough knowledge of .NET platform

Related Jobs:

• .NET Consultant
• Sales Representative
  

If you are interested and are able to fulfill many of the above requirements, please let us know. Do not hesitate to ask questions. We look forward to your response.

Email to: edgar(dot)sanchez(at)ipcas(dot)de

A few days ago we had an inquiry in regard to the license server used for the floating license model. Our customer configured the license server, however, he did not bear in mind the note: Use UNC path. Therefore, I have decided to make a small entry here in order to leave a reference for future inquiries.

UNC path is the Universal/Uniform Naming Convention that describes the location of a volume, directory, or file. The format for a UNC path is \\server\volume\directory\file-name and is not case-sensitive. If the configuration of the license server is performed either directly onto the server or from another computer, this UNC path should remain identical throughout the network, since this information is encrypted within the license file.

For example, if a user installing SpeedTrace within a network (illustrated below) configures and activates the license server directly onto the server with a specific UNC path (e.g., \\192.145.342.5\SpeedTraceServer\License.lic), other computers attempting to connect to this license server need to use exactly the same UNC path, otherwise the license server interprets this request as either system tampering or “Installation code does not match”.

The same principle is applied when companies have teams abroad.