Re(4): URL Access performance tuning
Re(4): URL Access performance tuning
- Subject: Re(4): URL Access performance tuning
- From: Jens Bauer <email@hidden>
- Date: Tue, 21 May 2002 18:10:21 +0200
Hi Bryan,
On Tue, 21 May, 2002, Pietrzak, Bryan <email@hidden> wrote:
>
I guess the answer to "who cares" is me. I don't want to develop an app that
>
is a resource hog. If I do that and then five other developers do that then
>
OS X networking sucks. That's bad.
I follow you here. If you're on the optimizing stage, and you aren't pre-
researching, I agree.
It's also my policy to optimize my applications, so that instead of being
only able to run one, you would be able to run 10 without feeling the
difference. Unfortunately, you can't always control other developers
thoughts and opinions. ;)
>
So, as a good developer I've got my algorithm working (based on URL Access)
>
and now I'm fine tuning.
>
>
Anyway, each time the app runs and the users goes online to play (it's a
>
series of card games) I make one connection to download an XML formatted
>
config file. This file is usually no more than 2-3K tops, so it'll be
>
transparent to the user.
>
>
Then, I parse this file and, as needed, download new artwork and such. So,
>
generally, there won't be frequent downloads, it won't be a common occurence
>
to change the online look and feel.
If this is the server-part, I do see that you want to keep the clock-
cycles down.
-But if it's a client application, I am very convinced that you don't
need to worry too much.
Ofcourse; I can be wrong, and you have *seen* the application run, and
know where it's heading. =)
I'd recommend downloading the new artwork "slowly" in the background, if
you have the chance.
You could request small chunks of data, rather than a full 32MB file at once.
Yet again, don't make the packages too small, because the TCP/IP header
uses some space as well, so does a standard HTTP header, if you plan to
use HTTP for that transfer..
If you want to save bandwidth, you could go UDP, and I would recommend
using CFSocket or BSD, as these are easy to work with. (I'd like to
mention, that before I go too far in my opinions, you should always
listen to what Quinn says rather than me, because I don't even reach the
top of his socks, when it comes to networking. ;))
I recall I wrote a very *fast* sprite routine for the Atari ST, because
one of my friends needed it.
It would output 200 32x32 sprites per VBL, and I was proud. -He told me
it *had* to be *very* fast.
Now, he used it for drawing pieces on a board in a turn-based game. Argh! :)
-I used to assembly-optimize everything, but from that day, I didn't
really care anymore.. Basic optimization was enough. ;)
Love,
Jens
--
Jens Bauer, Faster Software.
-Let's make the World better, shall we ?
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.