Re: Is Mac Mini capable to develop cocoa app?
Re: Is Mac Mini capable to develop cocoa app?
- Subject: Re: Is Mac Mini capable to develop cocoa app?
- From: Mark Dawson <email@hidden>
- Date: Fri, 11 Mar 2005 10:31:57 -0800
On Mar 11, 2005, at 9:43 AM, Andy Armstrong wrote:
On 11 Mar 2005, at 16:36, Mark Dawson wrote:
All that said, if you are going to develop, 512 MB is the absolute
min, and 1 GB is the preferred choice.
As has been mentioned elsewhere on the thread a nice big display is
probably as important as anything. A lot of your development time is
spent using a text editor - not the most cycle hungry application.
Being able to see plenty of what you're editing is a huge advantage.
I would agree. Dual monitors are a good option, too (even if different
sizes)--they allow you to have your debugger in one window and your app
in another.
However, I would say that bigger screens is a much bigger end-user
issue than speed (mentioned below). You have to be careful in your UI
layout that you take in consideration that the user will likely have a
smaller screen area than you. I remember having put together a nice
UI arrangement, with plenty of screen room to spare, then running it on
an older 480x640 screen and it was horrible! I would say ALWAYS test
your UI on a 480x640 resolution to double check this (unless you're
target pros, who probably would never have that config).
If build speed is really a problem I'm sure you can lash together a
couple of cheap Linux boxes and make a compile farm :)
Distributed builds (see the XCode mailing list archives) seem to have a
certain amount of overhead (and you want the "head" machine to be the
fastest). From the reports that I've seen, a Dual 2.5 GHz (plenty of
RAM) is over 2.5-3x faster at compiling than a mini (1.42). XCode WILL
use both processors, so you do get a nice benefit from a dual machine.
When RAM is taken into effect, a mini is a little more than 1/3 the
cost of a dual. If you are doing big projects, a dual is the way to
go. If you're doing medium projects a mini would work just fine--its
really a decision based on your work habits vs the cost of your time
(i.e., how much time do you spend compiling & linking in your day).
Bear in mind also that if you only have one machine and it's the
fastest thing on the block you won't get much of an idea about parts
of your application that might be unacceptably slow on an older
machine.
But by finishing quicker, you'll actually have time to run the
profiling tools and tune it up. The best solution would be to buy an
old 400 MHz G4 (with 128 MB of memory!) (iMac, Tower, etc). And use IT
as your test subject. That way you can feel the slowdowns (even w/o
running the profiling tools), but you won't be effected by having to
develop on that machine. Being on a "worse" machine simply to "feel
the pain" causes premature optimization (optimizing while you're still
changing the code, meaning that you could optimize the same section
many times). I been there, and the productivity hit is horrible! The
other problem is that you have no idea of what the baseline really
is--its slower so things will naturally be slower. Without running a
profiling tool (like Shark), you still don't have any idea if the
slowdown is the machine speed/memory configuration or actual problems
in your code. So you still have to rely on profiling.
A dual 2.5 might get you 5 (could be a lot more) more compiles & links
a day than a mini. Over a 6 month project, that really adds up.
Additionally, it REALLY speeds up the profiling! Running malloc debug,
guard malloc, and any memory thrashing tools can mean the difference of
minutes getting your app launched depending on the speed of your
machine (on one OS 9 project, the difference was 40 min vs 10 min--a
HUGE productivity gain).
For development purposes, I'd say get the fastest machine you can
afford, with caveat that RAM is important, also (i.e., I would guess
that a 1.25 1 GB mini is a faster development machine than a 1.42 256
MB mini). The bigger your project, the more important screen size is;
consider two displays.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden