So analyzer is now telling me i have a memory leak. In the function below it says 'potential leak of an object allocated into 'theAudio'
I think it speaks the truth because the app works well for a few minutes then slowly crashes.
I've tried 'autorelease' but it tells me 'object sent autorelease too many times'.
Sorry to be a pest but does anybody have any ideas on this?
-(void) playFile:(NSString*) nameOfFile { // plays audio file passed in by a string
fileLocation = nameOfFile;
NSString *path = [[NSBundle mainBundle] pathForResource:nameOfFile ofType:#"mp3"];
AVAudioPlayer* theAudio = [[AVAudioPlayer alloc] initWithContentsOfURL:[NSURL fileURLWithPath: path] error:NULL];
[theAudio play];
[fileLocation release];
}
Haven't used this, but you probably need to keep a retain on the player (as you do) but then release it when you're done with it, e.g., when you get one of the AVAudioPlayerDelegate methods (so you need to implement the player's `delegate.)
Related
I have a large number of objects in Core Data. Does the following only load what is needed for the UI as and when is needed or does it load all objects up front?
NSFetchedResultsController does have a fetchedObjects property.. does it means it fetches everything upfront? What is the right way to fix this?
NSManagedObjectContext *context = # get from somewhere
NSManagedObjectModel *model = context.persistentStoreCoordinator.managedObjectModel;
NSDictionary *vars = #{...};
NSFetchRequest *fetchRequest = [model fetchRequestFromTemplateWithName:#"..."
substitutionVariables:vars];
NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc] initWithKey:#"..." ascending:NO];
NSArray *sortDescriptors = #[sortDescriptor];
fetchRequest.sortDescriptors = sortDescriptors;
NSFetchedResultsController *controller = [[NSFetchedResultsController alloc]
initWithFetchRequest:request
managedObjectContext:context
sectionNameKeyPath:nil
cacheName:#".."];
You generally shouldn't use fetchedObjects. It will always be the full list of fetched objects, some of which may be in memory and some may be faults.
The whole point is that you want the FRC to load data (to fault objects) only as required. But, for it to do that, you need to tell it how much to load based on what your UI can display at any one time (the maximum number of items that could be on screen at the same time).
To do that you need to set the fetchBatchSize on the NSFetchRequest. Once you've done that the FRC will load a new 'page' of results (into memory) as required (when your UI is scrolled and new requests are made to the FRC for data).
Technically, it isn't the FRC that's doing this, it's the array object returned by the fetch which initially contains 'empty' objects and which transparently faults batches of objects on demand.
Every time an event is triggered, my app records its date:
NSString *path = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
NSString *filename = [path stringByAppendingPathComponent:#"dates.dat"];
if (![[NSFileManager defaultManager] fileExistsAtPath:filename]) {
[[NSFileManager defaultManager] createFileAtPath:filename
contents:nil
attributes:nil];
}
NSFileHandle *wHandle = [NSFileHandle fileHandleForWritingAtPath:filename];
[wHandle seekToEndOfFile];
NSData *data = [NSKeyedArchiver archivedDataWithRootObject:[NSDate date]];
[wHandle writeData:data];
[wHandle closeFile];
I successfully record the events' dates. But now I am having troubles in reading them back. I tried this but the app crashes:
NSData *restore = [NSData dataWithContentsOfFile:filename];
NSArray *date1 = [NSKeyedUnarchiver unarchiveObjectWithData:restore]; // crash here!
I notice that it takes 223 bytes for each NSDate write but that is not officially mentioned. So I am afraid that using 223 bytes as length to parse the file "dates.dat" would cause problems later.
Do you have any ideas to read dates.dat into an NSArray so I can proceed its values?
Thanks in advance
Don't store the dates as arbitrary blocks of data in a file (because you're correct, you shouldn't rely on the number of bytes used for each date).
As a minimum, use a separator character (like a carriage return) so you know which data belongs to each different date. Then you need to parse the file and read in only the appropriate data before you try to unarchive it.
i've a problem with my table!
i use a parsing tableview but when i change view, my table loses data. So i decide to save all data to nsuserdefault; but, here the problem, NSUserDefault warns me:
"Note that dictionaries and arrays in property lists must also contain only property values."
NB: itemsToDisplay is a NSMutableArray and contain title, url, data and summary of parsedItems.
Well, here my code:
self.itemsToDisplay = [[[NSUserDefaults standardUserDefaults] arrayForKey:#"items"] mutableCopy];
if (!self.itemsToDisplay) {
self.itemsToDisplay = [[NSMutableArray alloc] init];
}
self.itemsToDisplay = [[NSMutableArray alloc]init];
self.itemsToDisplay = [parsedItems sortedArrayUsingDescriptors:
[NSArray arrayWithObject:[[[NSSortDescriptor alloc] initWithKey:#"date"
ascending:NO] autorelease]]];
[[NSUserDefaults standardUserDefaults] setObject:self.itemsToDisplay forKey:#"items"];
[[NSUserDefaults standardUserDefaults] synchronize];
I suppose the problem is setObject:self.itemsToDisplay, but i don't know how solve it.
Thank You guys..
First lets mention that the table cannot lose data because it does not hold any user data. The data is either provided through bindings or through delegation see NSTableViewDataSource in Apples documentation).
Second, the first three assignments to self.itemsToDisplay serve no purpose (unless you have side-effects in the setter) because they are all overridden by the last assignment.
Finally, if this code is already in the delegate then the delegate should be instantiated in your NIB file for the data to survive past a view swap. If your delegate is an object that is instantiated with your view it will also die with it along with all of the data and writing to the user-defaults is a bad idea for what you are trying to achieve. Simply set the delegate to an object whose lifetime is greater than that of both views.
self.itemsToDisplay = [parsedItems sortedArrayUsingDescriptors:
[NSArray arrayWithObject:[[[NSSortDescriptor alloc] initWithKey:#"date"
ascending:NO] autorelease]]];
//First lets encode it
NSUserDefaults *userDefault=[NSUserDefaults standardUserDefaults];
NSData *myEncodedObject = [NSKeyedArchiver archivedDataWithRootObject:self.itemsToDisplay];
[userDefault setObject:myEncodedObject forKey:[NSString stringWithFormat:#"sample"]];
EDITED WITH NEW CODE BELOW
I'm relatively newbie on Multithreading but to achieve my goal, doing it quickly and learning something new, I decided to do it using a multithread App.
The goal: Parse a huge amount of string from a file and save every word into the SQLite db using CoreData.
Huge because the amount of words is around 300.000 ...
So this is my approach.
Step 1. Parse all the words into the file placing it into a huge NSArray. (Done quickly)
Step 2. Create the NSOperationQueue inserting the NSBlockOperation.
The main problem is that the process start very quickly but than slow down very soon. I'm Using an NSOperationQueue with max concurrent operation setted to 100. I have a Core 2 Duo Process (Dual core without HT).
I seen that using NSOperationQueue there is a lot of overhead creating the NSOperation (stopping the dispatch of the queue it need about 3 min just to create 300k NSOperation.)
CPU goes to 170% when I start dispatching the queue.
I tryed also removing the NSOperationQueue and using the GDC (the 300k loop is done instantaneous (commented lines)) but cpu used is only 95% and the problem is the same as with NSOperations. Very soon the process slow down.
Some tips to do it well?
Here some Code (Original question Code):
- (void)inserdWords:(NSArray *)words insideDictionary:(Dictionary *)dictionary {
NSDate *creationDate = [NSDate date];
__block NSUInteger counter = 0;
NSArray *dictionaryWords = [dictionary.words allObjects];
NSMutableSet *coreDataWords = [NSMutableSet setWithCapacity:words.count];
NSLog(#"Begin Adding Operations");
for (NSString *aWord in words) {
void(^wordParsingBlock)(void) = ^(void) {
#synchronized(dictionary) {
NSManagedObjectContext *context = [(PRDGAppDelegate*)[[NSApplication sharedApplication] delegate] managedObjectContext];
[context lock];
Word *toSaveWord = [NSEntityDescription insertNewObjectForEntityForName:#"Word" inManagedObjectContext:context];
[toSaveWord setCreated:creationDate];
[toSaveWord setText:aWord];
[toSaveWord addDictionariesObject:dictionary];
[coreDataWords addObject:toSaveWord];
[dictionary addWordsObject:toSaveWord];
[context unlock];
counter++;
[self.countLabel performSelectorOnMainThread:#selector(setStringValue:) withObject:[NSString stringWithFormat:#"%lu/%lu", counter, words.count] waitUntilDone:NO];
}
};
[_operationsQueue addOperationWithBlock:wordParsingBlock];
// dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
// dispatch_async(queue, wordParsingBlock);
}
NSLog(#"Operations Added");
}
Thank you in advance.
Edit...
Thanks to Stephen Darlington I rewrite my code and I figured out the problem. The most important thing is: Do not share CoreData object between Thread ... it means do not mix Core data objects retrieved by different context.
This bring me to use #synchronized(dictionary) that result in a slow motion code execution!
Than I removed the massive NSOperation creation using just MAXTHREAD instance. (2 or 4 instead of 300k ... is a huge difference)
Now I can parse 300k+ String in just 30/40 seconds. Impressive!!
Still I have some issue (seams it parse more words than they are with just 1 thread and it parse not all the words if threads are more than 1 ... I need to figure it out) but now the code is really efficient. Maybe the next step could be using OpenCL and injecting it into the GPU :)
Here the new Code
- (void)insertWords:(NSArray *)words forLanguage:(NSString *)language {
NSDate *creationDate = [NSDate date];
NSPersistentStoreCoordinator *coordinator = [(PRDGAppDelegate*)[[NSApplication sharedApplication] delegate] persistentStoreCoordinator];
// The number of words to be parsed by the single thread.
NSUInteger wordsPerThread = (NSUInteger)ceil((double)words.count / (double)MAXTHREADS);
NSLog(#"Start Adding Operations");
// Here I minimized the number of threads. Every thread will parse and convert a finite number of words instead of 1 word per thread.
for (NSUInteger threadIdx = 0; threadIdx < MAXTHREADS; threadIdx++) {
// The NSBlockOperation.
void(^threadBlock)(void) = ^(void) {
// A new Context for the current thread.
NSManagedObjectContext *context = [[NSManagedObjectContext alloc] init];
[context setPersistentStoreCoordinator:coordinator];
// Dictionary now is in accordance with the thread context.
Dictionary *dictionary = [PRDGMainController dictionaryForLanguage:language usingContext:context];
// Stat Variable. Needed to update the UI.
NSTimeInterval beginInterval = [[NSDate date] timeIntervalSince1970];
NSUInteger operationPerInterval = 0;
// The NSOperation Core. It create a CoreDataWord.
for (NSUInteger wordIdx = 0; wordIdx < wordsPerThread && wordsPerThread * threadIdx + wordIdx < words.count; wordIdx++) {
// The String to convert
NSString *aWord = [words objectAtIndex:wordsPerThread * threadIdx + wordIdx];
// Some Exceptions to skip certain words.
if (...) {
continue;
}
// CoreData Conversion.
Word *toSaveWord = [NSEntityDescription insertNewObjectForEntityForName:#"Word" inManagedObjectContext:context];
[toSaveWord setCreated:creationDate];
[toSaveWord setText:aWord];
[toSaveWord addDictionariesObject:dictionary];
operationPerInterval++;
NSTimeInterval endInterval = [[NSDate date] timeIntervalSince1970];
// Update case.
if (endInterval - beginInterval > UPDATE_INTERVAL) {
NSLog(#"Thread %lu Processed %lu words", threadIdx, wordIdx);
// UI Update. It will be updated only by the first queue.
if (threadIdx == 0) {
// UI Update code.
}
beginInterval = endInterval;
operationPerInterval = 0;
}
}
// When the NSOperation goes to finish the CoreData thread context is saved.
[context save:nil];
NSLog(#"Operation %lu finished", threadIdx);
};
// Add the NSBlockOperation to queue.
[_operationsQueue addOperationWithBlock:threadBlock];
}
NSLog(#"Operations Added");
}
A few thoughts:
Setting max concurrent operations so high is not going to have much effect. It's unlikely to be more than two if you have two cores
It looks as though you're using the same NSManagedObjectContext for all your processes. This is Not Good
Let's assume that your max concurrent operations was 100. The bottle-neck would be the main thread, where you're trying to update a label for every operation. Try to update the main thread for every n records instead of every one
You shouldn't need to lock the context if you're using Core Data correctly... which means using a different context for each thread
You don't seem to ever save the context?
Batching operations is a good way to improve performance... but see previous point
As you suggest, there's an overhead in creating a GCD operation. Creating a new one for each word is probably not optimal. You need to balance the overhead of creating a new processes with the benefits of parallelisation
In short, threading is hard, even when you use something like GCD.
It's hard to way without measuring and profiling but what looks suspicious to me is your saving the full dictionary of words that have been saved so far with the save of each word. So the amount of data per save gets successively larger and larger.
// the dictionary at this point contains all words saved so far
// which each contains a full dictionary
[toSaveWord addDictionariesObject:dictionary];
// add each time so it gets bigger each time
[dictionary addWordsObject:toSaveWord];
So, each save is saving more and more data. Why save a dictionary of all words with each word?
Some other thoughts:
why build up coreDataWords that you never use?
I wonder if you're getting the concurrency you're since you're synchronizing the full block of work.
Things to try:
comment out the dictionary on the toSaveWord in addition to the dictionary you're building up and try again - see if it's your data/data structures or DB/coreData.
Do the first but also create a serial version of it to see if you're actually getting concurency benefits.
Here is my array:
MyTestArray=[NSMutableArray arrayWithObjects:#"Who invented america?",#"Fredrick",#"Colob bas",#"Alfred Novel",#"Sohel",nil];
I want to print it as follows :
NSLog(#"%#",[MyTestArray objectAtIndex:0]);
What i did wrong here?I just wanted to get value at the index.But my program is crashing here.:(
Just to check. what is the variable MyTestArray declared as? It should be declared as NSMutableArray.
UPDATED:
This is a memory problem. Are you retaining your MyTestArray? arrayWithObjects: method return an autorelease object. So it might only be valid for the current loop and being released when the next loop begin.
There's several way to retain object. I always recommend using property but for you it can be as simple as doing this.
MyTestArray = [[NSMutableArray arrayWithObjects:#"Who invented america?",#"Fredrick",#"Colob bas",#"Alfred Novel",#"Sohel",nil] retain];
Shouldn't crash now.