Hello all,
I saw an interesting reply from Dr. Hipp posted today:
http://www.mail-archive.com/sqlite-users@sqlite.org/msg62618.html
This seems to explain why SQLite (and Core Data) might sometimes launch and
execute very slowly.
-- Tito
On Sep 3, 2009, at 5:00 PM, Ben Trumbull wrote:
>
> On
On Sep 3, 2009, at 4:49 AM, Ruotger Skupin wrote:
Since it's not a many to many, you can perform the prefetching
effectively by hand using a fetch request to preload the relevant
destination rows with an IN query based on the data you initially
fetched for the source entity. You shouldn't
Am 26.08.2009 um 01:21 schrieb Ben Trumbull:
When I use setRelationshipKeyPathsForPrefetching the fetch throws:
-[NSSQLAttribute inverseRelationship]: unrecognized selector sent
to instance 0x10ee150
Can you provide the entire stack trace at this point ? gdb use
future-break objc_except
On Aug 25, 2009, at 7:19 AM, Ruotger Skupin wrote:
Am 24.08.2009 um 23:13 schrieb Ben Trumbull:
When I use setRelationshipKeyPathsForPrefetching the fetch throws:
-[NSSQLAttribute inverseRelationship]: unrecognized selector sent
to instance 0x10ee150
Can you provide the entire stack tra
Am 24.08.2009 um 23:13 schrieb Ben Trumbull:
When I use setRelationshipKeyPathsForPrefetching the fetch throws:
-[NSSQLAttribute inverseRelationship]: unrecognized selector sent
to instance 0x10ee150
Can you provide the entire stack trace at this point ? gdb use
future-break objc_except
On Aug 24, 2009, at 3:20 AM, Ruotger Skupin wrote:
Am 20.08.2009 um 22:28 schrieb Ben Trumbull:
setRelationshipKeyPathsForPrefetching
When I use setRelationshipKeyPathsForPrefetching the fetch throws:
-[NSSQLAttribute inverseRelationship]: unrecognized selector sent to
instance 0x10ee15
Am 20.08.2009 um 22:28 schrieb Ben Trumbull:
setRelationshipKeyPathsForPrefetching
When I use setRelationshipKeyPathsForPrefetching the fetch throws:
-[NSSQLAttribute inverseRelationship]: unrecognized selector sent to
instance 0x10ee150
For the record: I do use one-way relationships
Ru
On Aug 20, 2009, at 02:35, Ruotger Skupin wrote:
Complex locale aware Unicode text queries can be slow. If you
find yourself spending time with such a query, you should consider
some of the techniques shown in the DerivedProperty example
available on ADC.
Isn't all text Unicode?
No.
On Aug 20, 2009, at 2:34 AM, Ruotger Skupin wrote:
Am 19.08.2009 um 22:00 schrieb Ben Trumbull:
I debugged it with some Snow Leopard magic and found out, that
firing
faults is very slow the first time after boot. When I use -[NSArray
filteredArrayUsingPredicate:] the fault firing is killin
ok
best,
gary
ToothPics Company
1.800.218.0531
On Aug 20, 2009, at 2:16 AM, Ruotger Skupin
wrote:
Am 20.08.2009 um 04:38 schrieb M Pulis:
I got that, Bill, thank you.
The OP did not specify what particular sql store (we still do NOT
know) nor if he is compiled Universal, has any he
On Aug 19, 2009, at 10:38 PM, M Pulis wrote:
My whole deal was about any PPC tasks in the OP's product's chain of
execution, as I.S. selectively missed then exaggerated the off
topic point (#5 of 8) in his surgical excerpt of my detailed
response to his questioning of my suggestion to the
Am 20.08.2009 um 11:34 schrieb Ruotger Skupin:
Am 19.08.2009 um 22:00 schrieb Ben Trumbull:
I debugged it with some Snow Leopard magic and found out, that
firing
faults is very slow the first time after boot. When I use -[NSArray
filteredArrayUsingPredicate:] the fault firing is killing me
Am 20.08.2009 um 04:38 schrieb M Pulis:
I got that, Bill, thank you.
The OP did not specify what particular sql store (we still do NOT
know) nor if he is compiled Universal, has any helper programs, etc,
he did however, describe symptoms I have seen with Rosetta. So I
simply proposed che
I got that, Bill, thank you.
The OP did not specify what particular sql store (we still do NOT
know) nor if he is compiled Universal, has any helper programs, etc,
he did however, describe symptoms I have seen with Rosetta. So I
simply proposed checking that no PPC code was being engaged. S
No offense taken... as you saw, I have no problem even proving myself
wrong to correct my postings.
I suggested testing for the possibility of non-native code. Warming up
Rosetta was NOT presented not as a solution but an aid to test the
presence of rather than assuming not. My ego permits
On Aug 19, 2009, at 5:21 PM, M Pulis wrote:
You may know, but I have no idea what versions are installed on any
given system, much less the OP's, responders, etc (you can execute
PPC frameworks onto an Intel machine, yes?) what frameworks are in
play, etc; and simply pose the question.
.
On Aug 19, 2009, at 2:21 PM, M Pulis wrote:
responders, etc (you can execute PPC frameworks onto an Intel
machine, yes?)
No, not from an native app.
Sorry 'bout that.
Extremely unlikely that Rosetta is the OP's problem unless there
is something like a helper app that is getting launc
On Aug 19, 2009, at 2:21 PM, M Pulis wrote:
The sqlite question was a reference to tito saying his experience
was "years ago" when the possibility of a non-native sqlite on an
intel machine was absolutely real and significantly less surprising.
You may know, but I have no idea what versions
The sqlite question was a reference to tito saying his experience was
"years ago" when the possibility of a non-native sqlite on an intel
machine was absolutely real and significantly less surprising. You may
know, but I have no idea what versions are installed on any given
system, much les
On Aug 19, 2009, at 4:56 PM, Bill Bumgarner wrote:
"Is SQLite" native" seems to be the one point on which all your
others hinge. I'd be dutifully surprised if it were not.
It is flat out impossible. A task -- a running program -- is either
all PPC or all Intel or all 32 bit or all 64 bit.
On Aug 19, 2009, at 1:05 PM, I. Savant wrote:
On Aug 19, 2009, at 3:55 PM, M Pulis wrote:
(5) tito was close with "warmupfile" workaround (is sqlite native???)
"Is SQLite" native" seems to be the one point on which all your
others hinge. I'd be dutifully surprised if it were not.
It is
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
On Aug 19, 2009, at 3:55 PM, M Pulis wrote:
(5) tito was close with "warmupfile" workaround (is sqlite native???)
"Is SQLite" native" seems to be the one point on which all your
others hinge. I'd be dutifully surprised if it were not.
--
I.S.
__
when fetching about 5000 objects from an sql store, Core Data is very
slow the very first time after a boot. When running the app the first
time it takes 50 to 90 seconds and when starting it the second time it
is well below one second.
Properly done, you could fetch 5000 objects on an original
(1) The subject: "Re: Core Data dog-slow when using first time after
boot"
(2) contains the key phrase "dog slow when using first time after boot"
(3) I know that Rosetta only "starts" once and takes a lot of time,
but not until the first non-native code hits.
On Aug 19, 2009, at 3:09 PM, M Pulis wrote:
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'm not sure how you've arrived at this conclusion based on the
messag
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
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
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 tri
On Aug 19, 2009, at 1:14 PM, Ruotger Skupin wrote:
I debugged it with some Snow Leopard magic and found out, that
firing faults is very slow the first time after boot. When I use -
[NSArray filteredArrayUsingPredicate:] the fault firing is killing me.
So I recoded it to fetch everything upf
Am 19.08.2009 um 18:38 schrieb Nick Zitzmann:
On Aug 19, 2009, at 4:13 AM, Ruotger Skupin wrote:
when fetching about 5000 objects from an sql store, Core Data is
very slow the very first time after a boot. When running the app
the first time it takes 50 to 90 seconds and when starting it
On Aug 19, 2009, at 4:13 AM, Ruotger Skupin wrote:
when fetching about 5000 objects from an sql store, Core Data is
very slow the very first time after a boot. When running the app the
first time it takes 50 to 90 seconds and when starting it the second
time it is well below one second.
32 matches
Mail list logo
