Folks,
This sounds like Rosetta. If you are seeing this on an intel machine,
and if _any_ code in the execution path is non-intel, then Rosetta
will startup, blocking until ready.
I have an app called Rosetta Booster; when set as a login item,
Rosetta is engaged, initialized, and ready to go, specifically
reducing non-native first-app-startup-time to virtually the same as a
native app.
As this really might not be a Cocoa issue, drop me an off-list request
if you would like to see/test Rosetta Booster - it is freeware.
Gary
On Aug 19, 2009, at 11:10 AM, Tito Ciuro wrote:
Ruotger,
Interestingly enough, I experienced this behavior in my latest app
which doesn't use Core Data. It uses SQLite directly instead. I
recalled I had experienced this a long time ago (years ago) and
someone (I don't remember who and where) mentioned a solution/
workaround/hack, which involves reading the file. Let's call this
function warmUpFile():
FILE *my_stream = NULL;
const char *my_filename = ...;
size_t object_size = 1024;
size_t object_count = 1024;
char buf[object_size * object_count];
my_stream = fopen (my_filename, "r");
while (fread (&buf, object_size, object_count, my_stream) > 0);
fclose (my_stream);
I have timed it both modes, always after rebooting my computer:
Reboot > Launch app > sqlite3_open_v2 > do stuff == 35 seconds
Reboot > Launch app > warmUpFile() > sqlite3_open_v2 > do stuff == 7
seconds
Once warmUpFile() has been executed, let Core Data open the store
and see if it helps.
-- Tito
On Aug 19, 2009, at 10:45 AM, Ruotger Skupin wrote:
Am 19.08.2009 um 19:18 schrieb I. Savant:
Hmm ... time to hit the books if you haven't already:
http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdPerformance.html#/
/apple_ref/doc/uid/TP40003468
Have you tried anything suggested there?
Fetch Limits: Not tried
The App basically loads objects and displays them in a table, so I
can't fetch only half of them as sorting depends on the contents of
the objects. I do fetches with sort descriptors though, to keep
sorting time down (always below 0.1 sec).
Batch faulting: tried
It helps but it is still too slow.
Pre-fetching: not tried
But if I understand the document right it's just a special case of
Batch Faulting and I don't see any faults fired since I use Batch
Faulting anyway
Reducing Memory Overhead: most don't apply (Garbage Collection / no
temporary managed objects)
I set the undo manager to nil
Large Data Objects (BLOBs): not used
I'd say all object are under 1k
Would switching to a different store type (other than SQL) help?
The database is not that large (in my example 55MB) maybe an atomic
store has its advantages there?
Ruotger
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/tciuro%40mac.com
This email sent to tci...@mac.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/toothpic%40fastq.com
This email sent to tooth...@fastq.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
