6 ms·

Beware the UIKit Visitors

74 points by panic 10y ago

mpweiher 10y ago
Good sleuthing, sounds like an instance of "accidentally quadratic"[1]. It's a very easy thing to miss, especially if n is usually small. [1] http://accidentallyquadratic.tumblr.com http://accidentallyquadratic.tumblr.com
Alphasite_ 10y ago
Ive had performance issues with UIColour and NSColour in the past as well, specifically to do with colour space conversion in my case.
- hanief 10y ago
  Did you mean UIColor and NSColor? :)
vbezhenar 10y ago
Using a binary library is always a nightmare. That aspect in Cocoa is terrifying after Java. With all that openness I really don't understand why Cocoa is closed-source. They could open it with "read only" license, it's not like someone could get any benefit from it.
- ttflee 10y ago
  Perhaps for fear of private APIs being used/abused by 3rd party?
  - mahyarm 10y ago
    We can already do that with dissemblers and objective-c header creators. It's the apple way, closed by default.
chedabob 10y ago
To make working with the assembly code easier, I've found Facebook's Chisel (specifically the "pinvocation" command) to be really useful: https://github.com/facebook/chisel https://github.com/facebook/chisel
- schwarrrtz 10y ago
  Chisel is awesome. pviews is another great command, it prints the view hierarchy along with the object addresses so you can easily send messages to a specific view. This is handy for changing properties during runtime, for example.
  - erichocean 10y ago
    Reveal[0] is super useful for doing view introspection at runtime. Easily paid for itself. [0] http://revealapp.com/ http://revealapp.com/
leonatan 10y ago
I don't see why the debugging had to take place on 32bit binary. From experience, the debugger disassembly for 64bit is much more "readable" - as in much of the symbols called are spelled out a lot more, and accessing function arguments are much much more friendly - "po $arg1" instead of register math. Hopper is capable of parsing 64bit disassembly and create pseudo code from that as well, if you need it.
- sjtgraham 10y ago
  Since when has Hopper been able to generate pseudocode for 64-bit ARM?
  - Ben-G 10y ago
    Author of the post here: this was my first serious foray into disassembly land and I remember one post pointing out that Hopper had a harder time with disassembling 64-bit slices. However, it appears that was wrong! About to add an update to the post.
  - LeoNatan25 10y ago
    x86-64; we are debugging on the simulator, remember?

74 points by panic 10y ago

Good sleuthing, sounds like an instance of "accidentally quadratic"[1]. It's a very easy thing to miss, especially if n is usually small. [1] http://accidentallyquadratic.tumblr.com http://accidentallyquadratic.tumblr.com

Alphasite_ 10y ago

Ive had performance issues with UIColour and NSColour in the past as well, specifically to do with colour space conversion in my case.

hanief 10y ago
Did you mean UIColor and NSColor? :)

vbezhenar 10y ago

Using a binary library is always a nightmare. That aspect in Cocoa is terrifying after Java. With all that openness I really don't understand why Cocoa is closed-source. They could open it with "read only" license, it's not like someone could get any benefit from it.

ttflee 10y ago
Perhaps for fear of private APIs being used/abused by 3rd party?
- mahyarm 10y ago
  We can already do that with dissemblers and objective-c header creators. It's the apple way, closed by default.

chedabob 10y ago

To make working with the assembly code easier, I've found Facebook's Chisel (specifically the "pinvocation" command) to be really useful: https://github.com/facebook/chisel https://github.com/facebook/chisel

schwarrrtz 10y ago
Chisel is awesome. pviews is another great command, it prints the view hierarchy along with the object addresses so you can easily send messages to a specific view. This is handy for changing properties during runtime, for example.
- erichocean 10y ago
  Reveal[0] is super useful for doing view introspection at runtime. Easily paid for itself. [0] http://revealapp.com/ http://revealapp.com/

leonatan 10y ago

I don't see why the debugging had to take place on 32bit binary. From experience, the debugger disassembly for 64bit is much more "readable" - as in much of the symbols called are spelled out a lot more, and accessing function arguments are much much more friendly - "po $arg1" instead of register math. Hopper is capable of parsing 64bit disassembly and create pseudo code from that as well, if you need it.

sjtgraham 10y ago
Since when has Hopper been able to generate pseudocode for 64-bit ARM?
- Ben-G 10y ago
  Author of the post here: this was my first serious foray into disassembly land and I remember one post pointing out that Hopper had a harder time with disassembling 64-bit slices. However, it appears that was wrong! About to add an update to the post.
- LeoNatan25 10y ago
  x86-64; we are debugging on the simulator, remember?