> As people often seem to do with such things, I was
> misinterpreting what it [Instruments] was telling me.
A really really simple way of getting a handle on where a
program is spending its time is to take a few samples in
Activity Monitor while it is busy. You'd be amazed at how well
this w
On Fri, Mar 12, 2010 at 2:41 PM, Gwynne Raskind wrote:
> (It's even more annoying because it *was* an NSPoint in a much earlier
> iteration of the code and I changed it because it simplified the code in two
> dozen places, and because the property in question is integer and doesn't
> need the s
On Mar 12, 2010, at 10:22 PM, Michael Ash wrote:
>> You're right; the specific call that's causing the worst speed issues is
>> returning a property typed with this structure:
>>
>> typedef struct { int32_t x, y; } IntegerPoint;
>>
>> It's not necessarily feasible to switch this to an NSPoint; i
On Fri, Mar 12, 2010 at 5:41 PM, Gwynne Raskind wrote:
> On Mar 12, 2010, at 4:52 PM, Peter Ammon wrote:
>>> While profiling a project I'm working on, I found that while most of my
>>> time was being spent in glFlush() (which is completely expected for an
>>> OpenGL-based game), a non-trivial am
On 12 Mar 2010, at 23:32, Gwynne Raskind wrote:
> On Mar 12, 2010, at 5:49 PM, Greg Parker wrote:
>>> You're right; the specific call that's causing the worst speed issues is
>>> returning a property typed with this structure:
>>>
>>> typedef struct { int32_t x, y; } IntegerPoint;
>>>
>>> It's
On Mar 12, 2010, at 14:41, Gwynne Raskind wrote:
> You're right; the specific call that's causing the worst speed issues is
> returning a property typed with this structure:
>
> typedef struct { int32_t x, y; } IntegerPoint;
>
> It's not necessarily feasible to switch this to an NSPoint; it mea
On Mar 12, 2010, at 5:49 PM, Greg Parker wrote:
>> You're right; the specific call that's causing the worst speed issues is
>> returning a property typed with this structure:
>>
>> typedef struct { int32_t x, y; } IntegerPoint;
>>
>> It's not necessarily feasible to switch this to an NSPoint; it
On 12 Mar 2010, at 22:41, Gwynne Raskind wrote:
> On Mar 12, 2010, at 4:52 PM, Peter Ammon wrote:
>>> While profiling a project I'm working on, I found that while most of my
>>> time was being spent in glFlush() (which is completely expected for an
>>> OpenGL-based game), a non-trivial amount o
On Mar 12, 2010, at 3:41 PM, Gwynne Raskind wrote:
> You're right; the specific call that's causing the worst speed issues is
> returning a property typed with this structure:
>
> typedef struct { int32_t x, y; } IntegerPoint;
>
> It's not necessarily feasible to switch this to an NSPoint; it
On Mar 12, 2010, at 2:41 PM, Gwynne Raskind wrote:
> You're right; the specific call that's causing the worst speed issues is
> returning a property typed with this structure:
>
> typedef struct { int32_t x, y; } IntegerPoint;
>
> It's not necessarily feasible to switch this to an NSPoint; it me
On Mar 12, 2010, at 4:52 PM, Peter Ammon wrote:
>> While profiling a project I'm working on, I found that while most of my time
>> was being spent in glFlush() (which is completely expected for an
>> OpenGL-based game), a non-trivial amount of time is being spent in dozens of
>> KVO internal met
On Mar 12, 2010, at 9:35 AM, Gwynne Raskind wrote:
> While profiling a project I'm working on, I found that while most of my time
> was being spent in glFlush() (which is completely expected for an
> OpenGL-based game), a non-trivial amount of time is being spent in dozens of
> KVO internal me
While profiling a project I'm working on, I found that while most of my time
was being spent in glFlush() (which is completely expected for an OpenGL-based
game), a non-trivial amount of time is being spent in dozens of KVO internal
methods and functions. Most especially, I noticed that KVO (or
13 matches
Mail list logo
