Um, are you really calling strlen() on a block of data there, on every
iteration through the loop?
This (a) won't work if the data has null-terminator (zero) bytes in it,
and (b) seems crazy slow. NSData has a method to get the number of bytes
in the data, use that.
So, um, have you verified that the data coming out of this function is
actually valid? I'd guess it's not…
Ben Einstein wrote:
Well,
I know what's happening, so I don't think Shark or Instruments can
help any. I just don't know WHY it happens.
This is the code i've been playing with (from Hayden Stainsby):
int i;
const char *thumbnailHex;
thumbnailHex = [thumbnailDataHex bytes];
for (i = 0; i < strlen(thumbnailHex); i += 2) {
char aByte, tChar[2];
tChar[0] = thumbnailHex[i];
tChar[1] = thumbnailHex[i+1];
tChar[0] -= 0x30;
if (tChar[0] >= 0x0a)
tChar[0] -= 0x07;
tChar[1] -= 0x30;
if (tChar[1] >= 0x0a)
tChar[1] -= 0x07;
aByte = tChar[0] << 4;
aByte = aByte | (tChar[1]);
[thumbnailData appendBytes:&aByte length:1];
}
thumbnailImage = [[NSImage alloc] initWithData:thumbnailData];
I've actually done a few tests where this method loops for longer than
90 seconds. On an NSImage object with the same number of bytes, it's
somewhere in the 0.1 second range.
So very confused...
Ben
On May 7, 2008, at 8:21 PM, John Stiles wrote:
Have you tried running Shark? That might give you some insight as to
what's going on.
Ben Einstein wrote:
Hi All,
I have an enterprise DB application that once used DO to move some
files around (images and zip files, mostly). After some serious
testing and lots of reading, I decided to move this to a few
different BLOB fields in the database. Despite major warnings from
people, I've found that images work great (specifically,
NSData/NSImage). I can notice a very minor speed drop a few
milliseconds, but being able to drop DO and it's woes is completely
worth it.
Unfortunately, I didn't quite test the zip files, figuring it would
be the same. I'm using Serge Cohen's MCPKit (aka SMySQL), which has
a nifty little function to convert NSData to a MySQL-legal NSString.
On the other end, someone on the Apple list posted a few lines of
code to bump returned data into it's original NSData object. With
the zip files (no larger then 600kb) that method takes 30 - 40
seconds to run. On an image of a similar size, it takes 0.1 seconds
on a slow day.
Does anyone know why this would be? Is there an easy way to get
around this? I suppose my understating of hex is lacking, but I
always thought a hex string was a hex string was a hex string;
length was all that mattered.
Thanks,
Ben Einstein
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com
<mailto: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/jstiles%40blizzard.com
This email sent to [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
_______________________________________________
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 [EMAIL PROTECTED]
