Re: [Proposal] On-the-fly NIB localization
Re: [Proposal] On-the-fly NIB localization
- Subject: Re: [Proposal] On-the-fly NIB localization
- From: Wade Tregaskis <email@hidden>
- Date: Wed, 17 Nov 2004 00:07:22 +1100
Also, it would slow down the entire system, because you're simply
transferring load from the hard disk onto the CPU. And these days,
with all the caches and lookaheads, the hard disk is the less
expensive bottleneck to get rid of.
Ha, try using an iBook.
Peak read/write performance is 10 meg a second, which isn't too bad all
things considered - *just* enough to stream losslessly-compressed DV
video to/from disk (although, not both at the same time, of course).
(Sadly not good enough for uncompressed video, which is a poor irony
given the older G3 iBook's can't compress DV video in real time).
But of course the "typical" read/write speed is closer to half a meg a
second, if that. Every additional disk seek costs big time - on the
order of 10's of ms, minimum. There's also a big CPU hit with each
additional seek (well, subjectively), which compounds the problem.
Beyond that it's all conjecture, but I did notice that even a 400mhz
G4, which by all rights should be CPU bound, upgrading the hard drive
from 25 meg/s to 50 meg/s (as a very rough comparison) made a huge
performance difference, on par with upgrading from 256 to 832 megs of
ram.
So imho disk I/O is still by far the greatest bottleneck, and becoming
worse given the trend towards even fatter applications - like
everyone's favourite "super light-weight" Firefox, weighing in at 24
meg... :( ...and app bundles, as compared to classical forked
applications, moving the bottleneck from a primarily memory-based one
to a primarily I/O-based one.
Anyone, back to the topic itself - I like where the original poster was
going to some degree... having dozens of different versions of the same
file seems like unnecessary redundancy to me, whether it's by design or
otherwise. The issues involved regarding button sizes and so forth are
of course very valid, but I imagine they could be largely solved by
trivial things such as auto-scaling controls and alternative interface
design paradigms - e.g. GTK doesn't work with co-ordinates so much as
divisions; you partition your window into multiple areas, which by
default auto-scale as appropriate for their contents... true, the
interface that results is generally pretty gross if you're not careful,
but there are nonetheless many virtues to this method.
Wade Tregaskis (AIM, Yahoo & Skype: wadetregaskis, ICQ: 40056898, MSN &
email: email@hidden, Jabber:
email@hidden)
-- Sed quis custodiet ipsos custodes?
_______________________________________________
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