[Biococoa-dev] [BioCocoa] Speed vs Safety
Alexander Griekspoor
a.griekspoor at nki.nl
Sun Aug 29 15:33:45 EDT 2004
A general discussion topic based on the emails from the last days.
Koen asked John a few times, why did you do this while we can do it in
one line of code, and the answer John gave was that he did quite some
error checking and in general expressed his concerns about
users/developers trying to execute malicious code.
Personally, I'm impressed by the safety John builds into his code, but
am worried that sometimes this goes a bit to far and might have the
opposite effect. Let me explain.
Up 'til now all of us have been producing end-user apps, and I bet you
if a user finds a way to do things wrong, they will (otherwise known as
Murphy's Law #128193 or something). And the developer has to prevent
this, so he builds a lot of safety measures and error checking in his
methods. But this time it's a bit different, we have someone in
between, the developer who uses our framework. And the way I see it, we
have to make sure that our methods do what they should according to the
docs, but the end responsibility of getting something from the end-user
and putting it in our framework in the right way lies at the developer.
One of the examples Koen mentioned was an accessor to set the
sequenceArray, which would normally be fairly easy:
-(void)setSequenceArray; (NSArray *)theArray{
NSArray *oldArray = sequenceArray;
sequence = [theArray copy];
[oldArray release];
}
or one of the well known variants.
In this particular example John thought "well, what if someone passes
an array that doesn't contain BCSymbols. but something else?", and adds
a method that enumerates over the array and checks if each object is of
class BCSymbol. It creates safety at the expense of speed/memory usage.
Imagine setting a 2.4Mb sequence.
The real question here is of course whether the increased safety is
worth the reduced speed and increased memory usage. I think not for a
number of reasons.
First, we create a well document framework that does what we say it
will do, and does it fast. It is the developers task to adhere to the
documentation and error check things he puts in. I also think this is
something not to unfair to expect from a developer, at least more than
from a end-user. Part of this is that the source is available, thus if
a developer gets an unexpected output/crash he should be able to find
out where things go wrong, something an end-user can't do. In return he
gets back a framework that is fast(er) and lightweight.
Also, our code becomes not only faster and less memory intensive, it
becomes more transparent as well.
Second, most of these crashes will occur during development (if the
developer does proper testing), a stage where crashes are less
important and where things can still be fixed/checked/circumvented by
the developer.
John also brought up the point that he does checking in case a
developer tries to "hack" stuff or change things he should change. Of
course we should make things private and inaccessible when we don't
developers to do that, but what if they really want to? What if they
find this way by messing with direct C calls? What if they do things
that messes up the whole framework, stalls things, crashes their app,
boggles down their laptop? Honestly I don't care! As long as do exactly
what is documented, do that job very well, and watch out for easy
pitfalls, then if someone wants to do it otherwise it is his problem.
Remember this is a developer, and developers are used to experiment,
let him. If he comes up with something really great because he changed
some stuff we didn't think of, or thought wasn't a good plan, great!
I'll be the first to applaud that. If he starts complaining that it
doesn't work then, well we can tell him to follow the documentation or
see if we can change some stuff.
Finally, I rather have the developer feel that he did something wrong
than us trying to mask/fix his mistakes. How many times did our apps
crash before we shipped it as we misused the Cocoa frameworks? Well
mine did very often. Then I fixed my mistakes and now my apps rarely
crash. And are perfectly Cocoa framework compatible in addition. And
that's the way it should be.
You quickly arrive at the discussion we have seen in the webbrowser
world hundreds of times. Many webpages are not 100% correct (in fact
most are not). The creators of webbrowsers had two options, either stop
rendering a page with incorrect syntax, or try to make the best of it,
Obviously the last option is only viable one if you have end-users that
certainly don't like a browser that only displays half the webpage you
give it. But this has one big disadvantage, website developers who see
that their (syntactically not 100% correct) webpages are rendered
perfectly fine, will publish these and won't put the effort in fixing
these 'bugs' as you get nothing in return for the effort spent. The
result is only more incorrect pages. Most code in safari is not in
rendering pages, it is in the code that tries to display something
useful of malformed webpages.
In our case we first of all have to legacy base, and second deal with
developers who have a problem if the framework doesn't pick their
malformed input, and most important of all, will then fix that.
The proposed "solution" is rather simple:
- document precisely what the developer should do and what he can
expect.
- in general go for speedy, transparent code with very general error
checking
- generate exceptions if input, parameter, and/or output is unexpected
Thus for the above setSequenceArray example: the compiler checks
whether an array is put in, so we can expect an array with potentially
unknown objects, but in principle that has no consequences for the rest
of THIS method, so no error checking needed here.
Other methods that depend on an array with proper types of objects
should rely on general exceptions raised by the cocoa framework
already, and furthermore only check if both input, parameters and
output is of an expected number/type ( as far as not already checked by
the compiler like in the above example).
Again, this probably has a lot to do with the switch from app to
framework development, and I'm sure we will have these kind of
discussions a lot more in the future. Let me know what you guys
think...
Cheers,
Alex
Ps. At WWDC's Cocoa optimization session we were told that in general a
for(i=0; i < x; i++), where x is [theArray count] is faster and less
memory intensive than an enumerator (no object messaging involved).
Although the latter is definitely more elegant, if we are looking at
speed bottlenecks with large sequences, this might be something to keep
in mind.
*********************************************************
** Alexander Griekspoor **
*********************************************************
The Netherlands Cancer Institute
Department of Tumorbiology (H4)
Plesmanlaan 121, 1066 CX, Amsterdam
Tel: + 31 20 - 512 2023
Fax: + 31 20 - 512 2029
AIM: mekentosj at mac.com
E-mail: a.griekspoor at nki.nl
Web: http://www.mekentosj.com
Microsoft is not the answer,
Microsoft is the question,
NO is the answer
*********************************************************
*********************************************************
** Alexander Griekspoor **
*********************************************************
The Netherlands Cancer Institute
Department of Tumorbiology (H4)
Plesmanlaan 121, 1066 CX, Amsterdam
Tel: + 31 20 - 512 2023
Fax: + 31 20 - 512 2029
AIM: mekentosj at mac.com
E-mail: a.griekspoor at nki.nl
Web: http://www.mekentosj.com
Microsoft is not the answer,
Microsoft is the question,
NO is the answer
*********************************************************
*********************************************************
** Alexander Griekspoor **
*********************************************************
The Netherlands Cancer Institute
Department of Tumorbiology (H4)
Plesmanlaan 121, 1066 CX, Amsterdam
Tel: + 31 20 - 512 2023
Fax: + 31 20 - 512 2029
AIM: mekentosj at mac.com
E-mail: a.griekspoor at nki.nl
Web: http://www.mekentosj.com
Mac vs Windows
65 million years ago, there were more
dinosaurs than humans.
Where are the dinosaurs now?
*********************************************************
More information about the Biococoa-dev
mailing list