Post

Replies

Boosts

Views

Activity

Objects, Allocation, Theory
Background: An NSDocument text editing based app. Each page of the document has its own textView for the main document and a textView for the header and the footer for a total of three textViews (and associated objects such as textContainers) for each page.Currently I have it optimized to the point of being able to load a 336 page, 102K word test document in 2.83 seconds and being ready to edit text. This means that with the test document, over 1000 textViews are being allocated, initialized, and added to a view in that time span. Not bad but I can never leave well enough alone, and, as a personal challenge, I would like to get this down to less than two seconds. The ultimate goal would be to have everything loaded and ready to edit before the dock icon finishes its first bounce.I mostly know enough about objective C to be dangerous. I am thinking one possible avenue of tinkering could be the way I allocated and use other objects such as attributed strings, arrays, dictionaries, etc.Here is where I would like some insight.Possible scenarios:// scenario 1// in a parent classNSMutableAttributedString *aMainStringOfText; -(void)setThingsUpForString:(NSMutableAttributedString *)theString { // assume aMainStringOfText has been allocated/initialized and // is being passed in [helperClass fiddleWithAttributes:theString]; } // in a helperClass -(void)fiddleWithAttributes:(NSMutableAttributedString *)stringToFiddleWith { // do some stuff with the attString }// scenario 2// in a parent classNSMutableAttributedString *aMainStringOfText; -(void)setThingsUpForString:(NSMutableAttributedString *)theString { // assume aMainStringOfText has been allocated/initialized and // is being passed in theString = [helperClass fiddleWithAttributes:theString]; } // in a helperClass -(NSMutableAttributedString *)fiddleWithAttributes:(NSMutableAttributedString *)stringToFiddleWith { // do some stuff with the stringToFiddleWith return stringToFiddleWith; }// scenario 3// in a parent classNSMutableAttributedString *aMainStringOfText; -(void)setThingsUpForString:(NSAttributedString *)theString { aMainStringOfText = [[NSMutableAttributedString alloc] initWithAttributedString:[helperClass fiddleWithAttributes:theString]]; } // in a helperClass -(NSAttributedString *)fiddleWithAttributes:(NSAttributedString *)stringToFiddleWith { NSMutableAttributedString *tempString = [[NSMutableAttributedString alloc] initWithAttributedString:stringToFiddleWith]; // do some stuff with the tempString return tempString; }Scenario 1 seems like the best use of resources and the most efficient. If I understand Objective C well enough, I get from this that one string object is created (aMainStringOfText) and all further fiddling happens on that string.Scenario 2 is where my understanding gets a bit murky. What is being returned from the helper class? Is it a pointer to the original string that was passed in? And since the string that was passed in was not the actual string, but a pointer to it (is this assumption correct?), then is the helper returning a pointer to the pointer?Scenario 3 seems like a big waste of resources. An attributed string is passed in, a mutable string is created so it can be changed, and then it is returned as an attributedString which is then allocated again as a mutable string. Wasteful? What happens to all these strings? Which one really winds up as the mainStringOfText?So what about this:// Scenario A// in the main class I need to unarchive some data aMainStringOfText = [[NSMutableAttributedString alloc] initWithAttributedString:[helperClass stringFromData:someData]]; // in helper class -(NSAttibutedString *)stringFromData:(NSData *)someData { NSAttributedString *aStringFromData = [unarchiveSomeData:someData]; return aStringFromData; }// Scenario B aMainStringOfText = [helperClass stringFromData:someData]]; // in helper class -(NSMutableAttributedString *)stringFromData:(NSData *)someData { NSMutableAttributedString *aStringFromData = [[NSMutableAttributedString alloc] initWithAttributedString:[unarchiveSomeData:someData]]; return aStringFromData; }In Scenario B, who owns the mutableAttributedString? Since it is created in the helper class, isn't the helper the owner? And if the helper gets deallocated, does the string go away? From a coding clarity standpoint, Scenario B is cleaner since the helper does all the allocating and the classes that call this helper class (which can be a lot of them) don't have to do all the allocating in their code. But is this really a good choice.These same examples could also apply to arrays and dictionaries, right? Or really any object that uses a *pointer?1. Which of these is a better choice from a resource management standpoint?2. Which is better from an speed standpoint?3. Which is better from a "best practices" standpoint?4. Other?
6
0
2.8k
May ’20
NSView scrollWheel crash
Hello,I am not sure where to put this but here it is. Every once in a great while, my app will crash--it just quits and disappears. The crash report is always the same. A snippit is below. It always happens when I am scrolling up and down in an open document. It seems like this is something in the Appkit and is out of my control. But there is always the possibility that this is a result of something I am doing although I can't figure out what it is. As I mentioned, it is very infrequent--maybe once a month? Any ideas?Application Specific Information:objc_msgSend() selector name: scrollView:scrollWheelWithEvent:Thread 0 Crashed:: Dispatch queue: com.apple.main-thread0 libobjc.A.dylib 0x00007fff762bc69d objc_msgSend + 291 com.apple.AppKit 0x00007fff49366033 forwardMethod + 2112 com.apple.AppKit 0x00007fff49414bb2 -[NSView scrollWheel:] + 3413 com.apple.AppKit 0x00007fff49366033 forwardMethod + 2114 com.apple.AppKit 0x00007fff49414bb2 -[NSView scrollWheel:] + 3415 com.apple.AppKit 0x00007fff49366033 forwardMethod + 2116 com.apple.AppKit 0x00007fff49414bb2 -[NSView scrollWheel:] + 3417 com.apple.AppKit 0x00007fff49366033 forwardMethod + 2118 com.apple.AppKit 0x00007fff49414bb2 -[NSView scrollWheel:] + 3419 com.apple.AppKit 0x00007fff49366033 forwardMethod + 21110 com.apple.AppKit 0x00007fff49414bb2 -[NSView scrollWheel:] + 34111 com.apple.AppKit 0x00007fff492a2367 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 684012 com.apple.AppKit 0x00007fff492a0667 -[NSWindow(NSEventRouting) sendEvent:] + 47813 com.apple.AppKit 0x00007fff49140626 -[NSApplication(NSEvent) sendEvent:] + 231014 com.apple.AppKit 0x00007fff4912e5e0 -[NSApplication run] + 75515 com.apple.AppKit 0x00007fff4911dae8 NSApplicationMain + 77716 libdyld.dylib 0x00007fff77a983d5 start + 1
9
1
1.4k
Feb ’20
NSDocument Revert Window
I have an NSDocument base app that used the Revert To saved function. It all works like it should but one nagging issue that I have wanted to solve for quite some time has now made its way to my to do list. From what I can figure out and observe, it seems like when you go into Revert and browse versions, every version (and there could be a lot of them) is created with the same document/windowController/Window/etc. that is used to create a normal document when launching the app. My app has a lot of stuff associated with each window which is totally unneeded when browsing the versions. My question(s) then are as follows:1. Is is possible to specify and use a different document/windowController/window setup for browsing and then capture the text from that setup if the user decides to revert to that version?2. Is there any detailed documentation that lays out the finer details for what happens when it goes into the browse versions and exits it? I suspect that NSDocumentController has a lot of say in this process but I haven't been able to find much information. I mostly looking for insights, ideas, etc. but any code snippets in Obj C are appreciated.Thank you.
0
0
493
Nov ’19