This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin Performance and stat()


On Thu, Jun 03, 2010 at 07:57:31PM -0700, Christopher Wingert wrote:
>>On Thu, Jun 03, 2010 at 05:32:46PM -0700, Christopher Wingert wrote:
>>Yeah, that's what I thought you were doing.  Given that the timestamps
>>don't indicate "elapsed time of function X", it's not always possible
>>to figure out how long a function takes by subtracting.  Subtracting
>>timestamps shows the delta between one time that someone thought to put
>>an strace_printf in the code and another time that someone thought to
>>put an strace_printf in the code.  There is no guarantee that there is
>>an strace_printf at entry or exit of a function.
>
>Yes, except that someone instrumenting the entry/exit points was me,
>and the fact that they are not actually real syscalls and no other
>cygwin processes are running says the timestamps are accurate for the
>purposes of debugging.  Further the numbers match up with the overall
>timings I did before the debugging.

Ok, if you carefully added your own debugging calls then that's a
different story.  I don't see where you mentioned that anywhere until
now but, nevertheless, if you've added your own entry/exit debugging
then observation withdrawn.

>>It is a shame that we weren't more standardized in our strace output so
>>that kind of thing could be possible.
>
>Agreed (for once), the instrumentation of the syscalls and the fact that
>they are sprinkled over multiple files made things very difficult to
>debug.

It's not terribly unusual to have syscalls in different files.  In fact,
it's probably unusual to have so many in one file, like we do with
Cygwin.  That's another historical artifact.

>>However, for Cygwin, the web site says multiple times in multiple
>>places that you shouldn't send private email and to use the mailing
>>list.  So, other projects aside that really is how we do things here.
>
>Understood.  I'll wait with bated breath for a knowledgeable developer
>to speak up.

I'm glad not to contribute to your anoxia.  I do qualify as a
knowledgeable developer.  In fact, I'm one of the two people who would
approve/deny any patch.

Btw, if you are considering a patch, you should check out the link on
the website for what you need to do there.  In a nutshell: we have a
procedure similar to the FSF except that changes need to be assigned to
Red Hat.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]