Professional Web Applications Themes

Accessor speeds - Mac Programming

Am I right in assuming that it's faster to use a local variable than to use an accessor method to get a variable stored in another object? Or have the compilers become so efficient that there is no speed difference? -- C Lund, www.notam02.no/~clund...

  1. #1

    Default Accessor speeds

    Am I right in assuming that it's faster to use a local variable than
    to use an accessor method to get a variable stored in another object?
    Or have the compilers become so efficient that there is no speed
    difference?

    --
    C Lund, www.notam02.no/~clund
    C Guest

  2. #2

    Default Re: Accessor speeds

    In article <chello.com>,
    C Lund <no> wrote:
     

    You are right that there is a speed difference. The ObjC runtime is
    flexible enough that the compiler simply can't know that you're just
    calling an accessor. For all it can tell, [obj someValue] might end up
    calling over a Distributed Objects connected to a remote machine, or
    displaying a window, or anything else. So you have the full message send
    overhead.

    But don't go around removing all of your accessors and making things
    faster. You don't need the speed most of the time. Don't make ugly
    optimizations until you've run your program with
    Shark/Sampler/gprof/whatever to determine exactly what is slow. As the
    classic quote says, "Premature optimization is the root of all evil."
    Michael Guest

  3. #3

    Default Re: Accessor speeds

    In article <mail-355D7A.11103010102003localhost>,
    Michael Ash <com> wrote: 
    > You are right that there is a speed difference. The ObjC runtime is
    > flexible enough that the compiler simply can't know that you're just
    > calling an accessor. For all it can tell, [obj someValue] might end up
    > calling over a Distributed Objects connected to a remote machine, or
    > displaying a window, or anything else. So you have the full message send
    > overhead.[/ref]

    That's what I thought.
     

    Yeah, I know. I've been doing some optimization to my code and it *is*
    getting messy. However, the variables in question are called every
    time the image is drawn and there will be tens of thousands of them,
    so in this case I think it'll be worth it. B)

    --
    C Lund, www.notam02.no/~clund
    C Guest

  4. #4

    Default Re: Accessor speeds

    In article <chello.com>,
    C Lund <no> wrote:
     
    > > You are right that there is a speed difference. The ObjC runtime is
    > > flexible enough that the compiler simply can't know that you're just
    > > calling an accessor. For all it can tell, [obj someValue] might end up
    > > calling over a Distributed Objects connected to a remote machine, or
    > > displaying a window, or anything else. So you have the full message send
    > > overhead.[/ref]
    >
    > That's what I thought.

    >
    > Yeah, I know. I've been doing some optimization to my code and it *is*
    > getting messy. However, the variables in question are called every
    > time the image is drawn and there will be tens of thousands of them,
    > so in this case I think it'll be worth it. B)[/ref]

    Probably not, actually. The overhead is of sending a message, while not
    zero, is very small. You really should profile your code and figure out
    what's actually slow before you start changing things that you think are
    slow.

    For image processing, you'll probably speed things up most by caching
    data, drawing less often, and/or drawing less data each time.

    -Eric

    --
    Eric Albert edu
    http://rescomp.stanford.edu/~ejalbert/
    Eric Guest

  5. #5

    Default Re: Accessor speeds

    In article <chello.com>,
    C Lund <no> wrote:
     

    When it comes to this kind of thing, "I think" usually is a bad sign.

    If it's simple caching of a value, IMO that can simply make things
    clearer and you may as well do it. So instead of [obj thing]...[obj
    thing] all over the place, you do int thing = [obj thing], then use
    thing. But if it makes your code harder to read instead of easier, hold
    off on it until you *know* it'll be slow. Very often, the parts that you
    think will be slow and the parts that are actually slow are not the
    same. Wait until your program is working, then run it under a profiler
    (Shark from CHUD is really excellent) and see what is actually taking up
    most of your time. Shark will go as far as showing you line-by-line
    which statements take how much execution time.
    Michael Guest

  6. #6

    Default Re: Accessor speeds

    In article <mail-0C657D.11283811102003localhost>,
    Michael Ash <com> wrote: 
    > When it comes to this kind of thing, "I think" usually is a bad sign.[/ref]

    B)
     

    That's the case - for the most part. But I'll also have to include
    methods that run periodic updates now and then to store new values as
    they change - and that makes the code a little more complicated in
    places.
     

    Ok, I'm convinced. I'll let it be for now. B)

    --
    C Lund, www.notam02.no/~clund
    C Guest

  7. #7

    Default Re: Accessor speeds

    In article <chello.com>, C Lund
    <no> wrote:

    <snips> 

    2c:

    Again, follow the above advice: profile, profile, and profile again.
    While you certainly want to be aware of all performance issues, and
    design accordingly, you must profile to get useful data.

    You probably are aware of the many design guidelines and performance
    tips available in every book, and even from Apple, so you've got a lot
    of material to draw from. But once you implement the code as you see
    fit, you have to get that profile data.

    The tools are there; if you need to, use them in stages and improve
    your code one step at a time.
    Mikey Guest

  8. #8

    Default Re: Accessor speeds

    In article <stanford.edu>,
    edu says... 
    >
    > Probably not, actually. The overhead is of sending a message, while not
    > zero, is very small. You really should profile your code and figure out
    > what's actually slow before you start changing things that you think are
    > slow.
    >
    > For image processing, you'll probably speed things up most by caching
    > data, drawing less often, and/or drawing less data each time.
    >
    > -Eric
    >[/ref]

    I've written some image processing code and when you are going over
    every pixel in a bitmap then those objc_msg_send() calls add up. In my
    case it was worth doing something about it as cacheing a few IMPs gave
    me a big speed boost.

    How did I know what IMPs to cache? As everyone else has suggested I got
    the code running and working first then used Shark to profile it. This
    immediately pointed at the methods that were called frequently making it
    easy to make worthwhile optimisations.
    James Guest

  9. #9

    Default Re: Accessor speeds

    James Weatherley <net> wrote:
     

    If you're doing image processing, you don't want, or need, to have
    have message sending or even a function call for every pixel.

    After all, image pixel values tend to be monomorphic over the
    entire image. So you can pull any polymorphism that there is
    out of the innermost pixel loop.

    That may lead to small amounts of duplication (the innermost
    pixel-processing loops, usually scan-lines), but it's more
    than worth it for an order-of-magnitude speed difference,
    even compared to function calls. At least for simple
    operations.

    Marcel
    Marcel Guest

Similar Threads

  1. CFC accessor method inserting carriage returns
    By Cory P. in forum Coldfusion - Advanced Techniques
    Replies: 1
    Last Post: April 6th, 03:54 PM
  2. 3rd NIC killz access speeds
    By Baba in forum Windows Server
    Replies: 0
    Last Post: June 30th, 01:17 PM
  3. Film Speeds
    By CRAIG PALME in forum Photography
    Replies: 1
    Last Post: July 28th, 05:47 PM
  4. LAN Speeds
    By Eric Abbiss in forum Windows Networking
    Replies: 1
    Last Post: July 2nd, 12:11 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139