Making inspectors faster and a better for every object
The BSInspectors have two flaws so far: they’re not as fast as they could/should be, and they only display those objects that have plugins in an informative way. The new release fixes both of the issues. The speed has been increased and the informations shown also increased.
The new version introduces a plugin classed BSGeneralInspector which shows every object as if it was a dictionary and lists its instance variables like keys. The plugin “only” displays the instance variables that are objects, native c data structures are not supported so far (I have no idea how to encode all the objects in a general way to provide them in the inspector window like i do with the objects).
The new release also provides improved speed for getting data from the target-app into Xcode. In previous versions the data was provided byte by byte resulting in an array of strings like:
{@"12",@"15",@"53",@"-50"}
Parsing this is slow. To improve the speed I increased the number of bytes per word to 4 bytes (sizeof(long)). Then I changed the conversion of the strings to data objects from the gdb-plugin to my own implementation. Converting the strings into numbers is also done by a function that performs less checks than strtol does. The speed is much better now, but shark reports that most of the time is spend in converting the string to a UTF8 string. Does anyone know of a way to convert a NSString (or CFString) into a c-array of characters (a UTF8String or cstring, that doesn’t matter)? Currently I use CFStringGetCharactersPtr() and CFStringGetCharacters() but I think they’re both not perfect for this propose.
The UTF8 conversation may also take place when the gdb-output is parsed and converted into arrays of strings, but i can’t change this part of the story.
The tradeoff when using 4 byte strings is that the resulting data is always x*4 bytes long (data with 13 bytes converts to 16 bytes automatically). But as the required length of the data is known when requesting it, a subrange of the data is returned. Creating the subrange is much faster than converting strings to data, so this tradeoff should be ok.