On Jun 21, 2008, at 11:46 PM, Mark Munz wrote:
I also recommend logging a bug with Apple against this issue. You
shouldn't need to jump through those sorts of hoops with
NSKeyedArchiver.
I did (as requested by an Apple engineer). He told me that this has
been fixed internally already, he cou
I also recommend logging a bug with Apple against this issue. You
shouldn't need to jump through those sorts of hoops with
NSKeyedArchiver.
On Wed, Jun 18, 2008 at 8:48 PM, Markus Spoettl
<[EMAIL PROTECTED]> wrote:
> On Jun 18, 2008, at 2:41 PM, Michael Ash wrote:
>>
>> Although it partially defea
On Jun 18, 2008, at 7:08 PM, Markus Spoettl wrote:
On Jun 18, 2008, at 5:04 PM, Adam R. Maxwell wrote:
It's not recommended, but have you tried using old-style archiving
as another approach? It used to be considerably faster than keyed
archiving under some circumstances.
I have thought
On Wed, Jun 18, 2008 at 11:48 PM, Markus Spoettl
<[EMAIL PROTECTED]> wrote:
> On Jun 18, 2008, at 2:41 PM, Michael Ash wrote:
>>
>> Although it partially defeats the purpose of using NSCoder, you'll
>> avoid this whole path if you stuff all four doubles into a single
>> NSData. Don't forget to use
On Jun 18, 2008, at 2:41 PM, Michael Ash wrote:
Although it partially defeats the purpose of using NSCoder, you'll
avoid this whole path if you stuff all four doubles into a single
NSData. Don't forget to use the byte-swapping functions to ensure that
they all have a consistent representation acr
On Jun 18, 2008, at 5:04 PM, Adam R. Maxwell wrote:
It's not recommended, but have you tried using old-style archiving
as another approach? It used to be considerably faster than keyed
archiving under some circumstances.
I have thought about trying this until I read it's deprecated since
On Jun 18, 2008, at 7:31 PM, Markus Spoettl wrote:
On Jun 18, 2008, at 2:50 PM, Quincey Morris wrote:
I suppose you could byte-move each group of 4 doubles in one NSData
and give that to the archiver instead. Or do it further upstream
and make a bigger array of numbers in a NSData. (But you
On Jun 18, 2008, at 16:31, Markus Spoettl wrote:
I'm not exactly sure about the speed, blocking the UI for 15 seconds
isn't the best idea and the real data will be even bigger. So, a
cure for NSKeyedArchiver's optimization would be great.
The fastest, easiest approach would be to put your
On Jun 18, 2008, at 2:50 PM, Quincey Morris wrote:
I suppose you could byte-move each group of 4 doubles in one NSData
and give that to the archiver instead. Or do it further upstream and
make a bigger array of numbers in a NSData. (But you'll have to deal
with endianness and -- egads! -- fl
On Jun 18, 2008, at 2:50 PM, Quincey Morris wrote:
I suppose you could byte-move each group of 4 doubles in one NSData
and give that to the archiver instead. Or do it further upstream and
make a bigger array of numbers in a NSData. (But you'll have to deal
with endianness and -- egads! -- fl
On Jun 18, 2008, at 14:17, Markus Spoettl wrote:
Exactly and the test data isn't particularly big. Any ideas how to
tell the archiver not to do this with my doubles (that doesn't
involve conversion to strings and back)?
I suppose you could byte-move each group of 4 doubles in one NSData
On Wed, Jun 18, 2008 at 5:17 PM, Markus Spoettl
<[EMAIL PROTECTED]> wrote:
> On Jun 18, 2008, at 1:59 PM, Quincey Morris wrote:
>>
>> Yes, but look at where the time is *really* being spent. At a guess,
>> finishEncoding is comparing every number object against every other number
>> object to see i
On Jun 18, 2008, at 1:59 PM, Quincey Morris wrote:
Yes, but look at where the time is *really* being spent. At a guess,
finishEncoding is comparing every number object against every other
number object to see if it can archive just one object of each
distinct numeric value. With the number o
On Jun 18, 2008, at 13:06, Markus Spoettl wrote:
I did profile it but it's not my code that is slow. It's the call to
[archiver finishEncoding] that's taking so long (see the Shark trace
below.
Regards
Markus
3.5% 57.0% CoreFoundation
__CFSetFindBucke
On Jun 18, 2008, at 12:35 PM, Michael Ash wrote:
I saw no mention in your message; have you profiled your app yet? Even
though the time is not being spent in your code, a profile can give
you an idea of what's taking up all this time, and may give you hints
as to how to make it go faster. First r
On Wed, Jun 18, 2008 at 2:13 PM, Markus Spoettl
<[EMAIL PROTECTED]> wrote:
> Hello List,
>
> I'm having a problem with a performance problem in NSKeyedArchiver which I
> can't find a cause for.
I saw no mention in your message; have you profiled your app yet? Even
though the time is not being spe
On Jun 18, 2008, at 11:25 AM, Kyle Sluder wrote:
On Wed, Jun 18, 2008 at 2:13 PM, Markus Spoettl
<[EMAIL PROTECTED]> wrote:
2) I also noticed that when I use the NSPropertyListXMLFormat_v1_0
instead
of binary, the process speeds up considerably, taking just below 10
seconds.
The problem with
Assuming you don't fix the issue:
On Wed, Jun 18, 2008 at 2:13 PM, Markus Spoettl
<[EMAIL PROTECTED]> wrote:
> 2) I also noticed that when I use the NSPropertyListXMLFormat_v1_0 instead
> of binary, the process speeds up considerably, taking just below 10 seconds.
> The problem with this is that t
Hello List,
I'm having a problem with a performance problem in NSKeyedArchiver
which I can't find a cause for. Let me first describe the data I'm
storing:
It's a simple object hierarchy consisting of the following
Root custom < NSCoding > compliant object
|-- ANodes (NSMutableArray)
19 matches
Mail list logo
