Designing for multitudinous objects
Designing for multitudinous objects
- Subject: Designing for multitudinous objects
- From: Erez Anzel <email@hidden>
- Date: Thu, 29 Jan 2004 11:42:17 -0500
[This is an offshoot of the "Notification redundancy" thread from
yesterday.]
I've been running into speed problems when there are tens of thousands
of objects in my CAD-like program. It's time for me to reconsider the
design.
In a nutshell, I could have around 100,000 objects which the user
imports/selects/edits/whatever, all in one command. Currently each
object broadcasts a notification when it is changed, and each window
controller is an observer. (My objects are not observers.) If there are
three open windows on the same data, that could be 300,000
notifications. So I agree, I should NOT have each object broadcast a
notification; instead, either the user action should do so, or each
object should notify its owner (the document) by setting some flag in
its owner.
I've been using the standard Cocoa approach of Undo, notifications,
etc.. I have an NSObject subclass, which itself has some subclasses. I
use polymorphism and inheritance extensively. My model (as in MVC) has
an NSMutableArray with a potentially massive number of TBDBasobj
objects.
I think that the 50,000 objects (and it could be way more) which I
referred to earlier should each be an NSObject subclass. Some users
work with just a few, or a few hundred, or a few thousand; it varies
widely. Each of these objects may be a point, or a polygon, or a couple
of other types. I have my TBDBasobj as my base object type (a direct
subclass of NSObject). Then I have TBDPoynt for my points, TBDPolly for
my polygons, etc. Most of the objects are in one array, which I
traverse for various purposes. All the classes which I mentioned have a
draw method (among many others), and use polymorphism in many of these
cases. The TBDBasobj has some fields common to all the objects, such as
a pointer to the document, a color, an object number, a "selected"
flag, a description (string), etc., so I use inheritance as well. I may
create a separate, simpler object type: when users have so much data,
it typically doesn't need a description string, object number, custom
color, etc. for each one.
Many years ago I used to use a non-object-oriented means of storing
collections like this. A couple of years ago I started using STL
collections, such as vector.
Perhaps I should even consider one massive block of memory (a C array)
to store struct's, where each struct represents a point. Then I could
have one instance of a TBDPoynt, and that instance would take on the
values of each point from the C array in turn when it comes time to
draw, etc. This is analogous to a dialog box having one floating
editable text field. I'd have one separate C array for all my polygons,
where the entry is just basic info about the polygon. Each polygon
would point to a separate C array containing all its vertices. This all
gets much more complicated when I factor in multiple Undo capability,
copy & paste, duplication, etc.
Maybe I can still use the classic Cocoa approach for storing objects,
and just revise how I use notifications.
I am also thinking strongly of moving away from NSMutableArray, as I
want to port my application to Windows. I figure on using Microsoft's
Visual C++ and Microsoft Foundation Classes, which I assume will be
similar to MacApp from years ago. So I'll have to totally revise my
Undo system, notifications, etc. anyway. I currently know nothing about
Windows or Windows development tools.
Any ideas or pointers?
Thanks...Erez
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.