First impressions are quite positive. The UI is clean and functional.
But I believe we are all here to try to help the product so I will focus on possible improvements that would make developers life easier.
On the start page, I would put a more descriptive message of what this tool will do for you, what are the goals of using a profiler and what values are really important to track. On each of the various panels that make the composite UI I would put something that when clicked, will show me what is this for and what values to track.
At one point, I had many panels with lots of information to look at. I understand that each project is different and that it maybe quite complicated to generalized what values should be considered “red flags†but it could be very valuable if the tool would highlight what is considered a possible "flag".
The hit count tells how many times u visited a procedure. It would be nice if some logic went into that process tracking and notify users that u called a procedure more than once but that no other procedure calls in between have altered the result of that repeated procedure ...making it unnecessary. For example, if you have a procedure that loads data, that’s IO and CPU intense. If by mistake you call that procedure 4-5 times and all other calls in between would not alter the number of records to load (for example changing UI colors, disabling some buttons …) then the profiler should highlight those 4-5 repeated calls as “red flagsâ€.
Another thing, I have tested a client that uses a web service. The tool highlighted one procedure from a file that is auto generated by Visual Studio to define the web service stub. Nothing I can do to change that file since it is auto generated. I understand I should refer to the procedure within my code that calls the WS stub procedure, but if could be nice if the profiler would do that for me.
One last comment ...and maybe the one thing I love the most in profiling SQL 2005. I would love seeing on this profiler a graphical representation of the application flow [this procedure took so long, and called this other procedure which took so long and ...bla bla bla) ...all visual and colorful.
That’s the best print out u can come out from a tool when u profile an application.
First impressions are quite positive. The UI is clean and functional.
But I believe we are all here to try to help the product so I will focus on possible improvements that would make developers life easier.
On the start page, I would put a more descriptive message of what this tool will do for you, what are the goals of using a profiler and what values are really important to track. On each of the various panels that make the composite UI I would put something that when clicked, will show me what is this for and what values to track.
At one point, I had many panels with lots of information to look at. I understand that each project is different and that it maybe quite complicated to generalized what values should be considered “red flags†but it could be very valuable if the tool would highlight what is considered a possible "flag".
The hit count tells how many times u visited a procedure. It would be nice if some logic went into that process tracking and notify users that u called a procedure more than once but that no other procedure calls in between have altered the result of that repeated procedure ...making it unnecessary. For example, if you have a procedure that loads data, that’s IO and CPU intense. If by mistake you call that procedure 4-5 times and all other calls in between would not alter the number of records to load (for example changing UI colors, disabling some buttons …) then the profiler should highlight those 4-5 repeated calls as “red flagsâ€.
Another thing, I have tested a client that uses a web service. The tool highlighted one procedure from a file that is auto generated by Visual Studio to define the web service stub. Nothing I can do to change that file since it is auto generated. I understand I should refer to the procedure within my code that calls the WS stub procedure, but if could be nice if the profiler would do that for me.
One last comment ...and maybe the one thing I love the most in profiling SQL 2005. I would love seeing on this profiler a graphical representation of the application flow [this procedure took so long, and called this other procedure which took so long and ...bla bla bla) ...all visual and colorful.
That’s the best print out u can come out from a tool when u profile an application.
Overall GREAT JOB guys. U surely test ur tools and provide us with so much help. U are a miracle for all of us !!!
Ciaooo all, for now
________________
Filippo Pandiani
Wow it was so good you said it twice. That's a lot of comments there which we'll have to look into detail more. I think the comment about flagging a procedure as being called but no alterations being made to the data is a hard problem. It would involve us examining your data structure in performance mode (which is meant to be fast) to see if things have changed. I can't see how this could be worked into something that could happen everytime a method is called - several million method calls for even the most simple of program.
But I believe we are all here to try to help the product so I will focus on possible improvements that would make developers life easier.
On the start page, I would put a more descriptive message of what this tool will do for you, what are the goals of using a profiler and what values are really important to track. On each of the various panels that make the composite UI I would put something that when clicked, will show me what is this for and what values to track.
At one point, I had many panels with lots of information to look at. I understand that each project is different and that it maybe quite complicated to generalized what values should be considered “red flags†but it could be very valuable if the tool would highlight what is considered a possible "flag".
The hit count tells how many times u visited a procedure. It would be nice if some logic went into that process tracking and notify users that u called a procedure more than once but that no other procedure calls in between have altered the result of that repeated procedure ...making it unnecessary. For example, if you have a procedure that loads data, that’s IO and CPU intense. If by mistake you call that procedure 4-5 times and all other calls in between would not alter the number of records to load (for example changing UI colors, disabling some buttons …) then the profiler should highlight those 4-5 repeated calls as “red flagsâ€.
Another thing, I have tested a client that uses a web service. The tool highlighted one procedure from a file that is auto generated by Visual Studio to define the web service stub. Nothing I can do to change that file since it is auto generated. I understand I should refer to the procedure within my code that calls the WS stub procedure, but if could be nice if the profiler would do that for me.
One last comment ...and maybe the one thing I love the most in profiling SQL 2005. I would love seeing on this profiler a graphical representation of the application flow [this procedure took so long, and called this other procedure which took so long and ...bla bla bla) ...all visual and colorful.
That’s the best print out u can come out from a tool when u profile an application.
First impressions are quite positive. The UI is clean and functional.
But I believe we are all here to try to help the product so I will focus on possible improvements that would make developers life easier.
On the start page, I would put a more descriptive message of what this tool will do for you, what are the goals of using a profiler and what values are really important to track. On each of the various panels that make the composite UI I would put something that when clicked, will show me what is this for and what values to track.
At one point, I had many panels with lots of information to look at. I understand that each project is different and that it maybe quite complicated to generalized what values should be considered “red flags†but it could be very valuable if the tool would highlight what is considered a possible "flag".
The hit count tells how many times u visited a procedure. It would be nice if some logic went into that process tracking and notify users that u called a procedure more than once but that no other procedure calls in between have altered the result of that repeated procedure ...making it unnecessary. For example, if you have a procedure that loads data, that’s IO and CPU intense. If by mistake you call that procedure 4-5 times and all other calls in between would not alter the number of records to load (for example changing UI colors, disabling some buttons …) then the profiler should highlight those 4-5 repeated calls as “red flagsâ€.
Another thing, I have tested a client that uses a web service. The tool highlighted one procedure from a file that is auto generated by Visual Studio to define the web service stub. Nothing I can do to change that file since it is auto generated. I understand I should refer to the procedure within my code that calls the WS stub procedure, but if could be nice if the profiler would do that for me.
One last comment ...and maybe the one thing I love the most in profiling SQL 2005. I would love seeing on this profiler a graphical representation of the application flow [this procedure took so long, and called this other procedure which took so long and ...bla bla bla) ...all visual and colorful.
That’s the best print out u can come out from a tool when u profile an application.
Overall GREAT JOB guys. U surely test ur tools and provide us with so much help. U are a miracle for all of us !!!
Ciaooo all, for now
________________
Filippo Pandiani