• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: CoreData performance issues
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreData performance issues


  • Subject: Re: CoreData performance issues
  • From: Tomek Piatek <email@hidden>
  • Date: Wed, 22 Jun 2005 14:07:43 +1200

This sounds "unusual". How are you determining uniqueness?

With the Project entity we just search for any projects with the matching name:


NSPredicate *predicate = [NSPredicate predicateWithFormat:@"name = % @", projectName];
[fetchRequest setPredicate:predicate];
...
NSArray* results = [managedObjectContext executeFetchRequest:fetchRequest error:&error];


We had a look at the sqlite database created by CoreData and the only indexing appears to be done on the relationships. There is no indexing done on attributes. Is there any way to force indexing on particular attributes?

Are you doing any additional processing?

No.

How long does it take simply to read and parse the data, without creating any managed objects?

Ingesting the records with checking for uniqueness on project names only took about 10 minutes. When we removed that check the time went down to about 26 seconds.


Just processing the file and not creating any managed objects take less than a second. This is done by commenting out the line:

        [self ingestRecord:record];

in the following "ingest" routine. So the "record" string is still created etc.

-(void)ingest
{
const char* databaseFileName = "/tech/home/jed/Projects/ HiDefDBTest/test_20000.txt";


    FILE* fh = fopen(databaseFileName, "r");

    if (fh == NULL)
    {
        NSLog(@"Could not open data file");
        exit(1);
    }

    NSDate* ingestStart = [NSDate date];

[self managedObjectContext];
_projectRequest = [[[NSFetchRequest alloc] init] autorelease];
NSEntityDescription* entity = [NSEntityDescription entityForName:@"Project" inManagedObjectContext:managedObjectContext];
[_projectRequest setEntity:entity];


_sceneRequest = [[[NSFetchRequest alloc] init] autorelease];
entity = [NSEntityDescription entityForName:@"Scene" inManagedObjectContext:managedObjectContext];
[_sceneRequest setEntity:entity];


_shotRequest = [[[NSFetchRequest alloc] init] autorelease];
entity = [NSEntityDescription entityForName:@"Shot" inManagedObjectContext:managedObjectContext];
[_shotRequest setEntity:entity];


_takeRequest = [[[NSFetchRequest alloc] init] autorelease];
entity = [NSEntityDescription entityForName:@"Take" inManagedObjectContext:managedObjectContext];
[_takeRequest setEntity:entity];


char lineBuffer[MAX_BUFFER_SIZE];
unsigned int lineCount = 0;
while (feof(fh) == 0)
{
NSAutoreleasePool* ingestPool = [[NSAutoreleasePool alloc] init];
if (fgets(lineBuffer, MAX_BUFFER_SIZE, fh) == NULL)
{
NSLog(@"Error reading line");
continue;
}


        ++lineCount;
        NSString* record = [NSString stringWithCString:lineBuffer];
        [self ingestRecord:record];
        [ingestPool release];
    }

NSDate* ingestEnd = [NSDate date];
NSLog(@"Ingested %d records in %f seconds", lineCount, [ingestEnd timeIntervalSinceDate:ingestStart]);


    [managedObjectContext save:nil];
}


How much memory is your application using? Is the hard drive thrashing? Is all the processing being done in a single "event loop" -- is there just one autorelease pool for the entire process...?

There are two autorelease pools. We added a second pool to the loop that processed each line of the text file because we were originally getting thrashing. The memory peaks at about 80Mb virtual, 40MB resident. The application was based on the Core Data Application template in XCode but we have no gui or nibs.


Running Shark over the application shows that 90% of the time the code is in the executeFetchRequest.

-tomek

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: CoreData performance issues
      • From: mmalcolm crawford <email@hidden>
  • Prev by Date: Re: dynamic libraries prpoblem
  • Next by Date: Re: CoreData performance issues
  • Previous by thread: Re: CoreData performance issues
  • Next by thread: Re: CoreData performance issues
  • Index(es):
    • Date
    • Thread