John's suggestion of getting rid of strlen was spot on; the code below
works extremely well if using [NSData length] a single time before the
loop.
What I'm still curious about is the difference in processing between
the NSImage and the zip archive. The same code and the same number of
bytes but orders of magnitude slower.
I should just quit while I'm ahead...
Ben
On May 7, 2008, at 11:01 PM, Matt Burnett wrote:
You could try encoding the data as Base64.It should keep it SQL safe
and there are plenty of APIs which can do it.
http://www.cocoadev.com/index.pl?BaseSixtyFour
On May 7, 2008, at 8:05 PM, 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)
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]
_______________________________________________
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/matt.w.burnett%40gmail.com
This email sent to [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]
