On Tuesday 02 December 2003 22:56, Mike McCormack wrote:
> I've been maintaining Charles's wine profiler patch in my Wine tree, but
> haven't tested it for a while. Here's roughly what I have at the
> moment... I'm in a bit of a rush right now, so it may be incomplete and
> I'll check it again ton
Andrew de Quincey <[EMAIL PROTECTED]> writes:
> As you say, relay debugging adds a huge overhead... however, would you say
> that this overhead would be fairly constant for each particular function?
No, it all depends on what other functions it is calling, and this may
change for each call.
>
On Tuesday 02 December 2003 18:21, Shachar Shemesh wrote:
> Dimitrie O. Paun wrote:
> >On December 2, 2003 08:52 am, Andrew de Quincey wrote:
> >>As you say, relay debugging adds a huge overhead... however, would you
> >> say that this overhead would be fairly constant for each particular
> >> func
Dimitrie O. Paun wrote:
On December 2, 2003 08:52 am, Andrew de Quincey wrote:
As you say, relay debugging adds a huge overhead... however, would you say
that this overhead would be fairly constant for each particular function?
And herein lies the problem: we're adding a _big_ constant ove
On December 2, 2003 08:52 am, Andrew de Quincey wrote:
> As you say, relay debugging adds a huge overhead... however, would you say
> that this overhead would be fairly constant for each particular function?
And herein lies the problem: we're adding a _big_ constant overhead (O)
to a variable cost
On Tuesday 02 December 2003 04:13, Alexandre Julliard wrote:
> Andrew de Quincey <[EMAIL PROTECTED]> writes:
> > However, if no one minds, I think I'll still implement the stuff I was
> > doing. I found being able to examine the call tree with ballpark figures
> > of how long was spent in each call
On Tuesday 02 December 2003 04:13, Alexandre Julliard wrote:
> Andrew de Quincey <[EMAIL PROTECTED]> writes:
> > However, if no one minds, I think I'll still implement the stuff I was
> > doing. I found being able to examine the call tree with ballpark figures
> > of how long was spent in each call
Andrew de Quincey <[EMAIL PROTECTED]> writes:
> However, if no one minds, I think I'll still implement the stuff I was doing.
> I found being able to examine the call tree with ballpark figures of how long
> was spent in each call was very invaluable.
Note that the relay debugging adds a huge o
On Monday 01 December 2003 22:35, Andrew de Quincey wrote:
> On Monday 01 December 2003 20:16, Mike Hearn wrote:
> > On Mon, 2003-12-01 at 12:49, Andrew de Quincey wrote:
> > > Hi, the last thing I have to do with the profiling stuff is the
> > > trickiest: To decide what is the best way to determi
On Monday 01 December 2003 20:16, Mike Hearn wrote:
> On Mon, 2003-12-01 at 12:49, Andrew de Quincey wrote:
> > Hi, the last thing I have to do with the profiling stuff is the
> > trickiest: To decide what is the best way to determine the times.
>
> It might be worth using oprofile, apparently in 2
On Mon, 2003-12-01 at 12:49, Andrew de Quincey wrote:
> Hi, the last thing I have to do with the profiling stuff is the trickiest: To
> decide what is the best way to determine the times.
It might be worth using oprofile, apparently in 2.6 at any rate it works
well with Wine.
> The problem is..
Hi, the last thing I have to do with the profiling stuff is the trickiest: To
decide what is the best way to determine the times.
To get times that are useful, I'm using the RDTSC opcode (which returns the
number of CPU clock cycles since the machine was powered on).. basically I've
added a cou
12 matches
Mail list logo
