Using large numbers of MVC triads 
Author Message
 Using large numbers of MVC triads

Has anyone out there experimented with a large number of
concurrent MVC triads?  Our group is putting together a tree browser,
and would like to have an individual pop-up menu for each node in the
tree.  The cleanest way to do this would be to have a separate view and
controller for each node, but with 20-50 nodes being shown in a window
at any one time, I am concerned about performance.

Given this, which is better--50 very simple controller-views,
each handling its own node, or one complex controller-view that can
handle the entire tree?  What kind of overhead is involved in adding
extra controller-views?

Thanks in advance,
   -Ron
-------------------------------------------------------------------
Ron Ferguson                   |  "Philosophy is the childhood of the

Michigan State AI/KBS Lab      | will never grow up." -T. Nagel
-------------------------------------------------------------------



Fri, 17 Dec 1993 03:50:39 GMT  
 Using large numbers of MVC triads

Quote:

>Has anyone out there experimented with a large number of
>concurrent MVC triads? ...
> ...The cleanest way to do this would be to have a separate view and
>controller for each node, but with 20-50 nodes being shown in a window
>at any one time, I am concerned about performance.

I haven't had an opportunity to use the new MVC stuff in the latest
ST-80 (I've been using ST/V for the last couple of years), so this
might not be completely accurate.

In my experience, building a interface out of lots of Views is a very
bad idea.  I tried this originally for a spreadsheet application, and
had a really rough time handling any decent sized spreadsheet.  I
eventually went for a very simple special-purpose object for each
cell, rather than a full-blown view.  The two big problems I had with
excessive use of sub-views were resources and performance.

The resource problem was partly due to the limited nature of the
Smalltalk platform I was working on - Smalltalk used to be limited to
32K objects, and views used up about 300+ each!  The special-purpose
cells I ended up with used under ten (I seem to remember).  This made
a huge difference in the number and size of spreadsheets I could have.
However, with modern Smalltalk technology, this shouldn't make as much
a difference, and if you're only talking about 50 or so views,
Smalltalk should be able to handle it.

The performance problem is a little more subtle.  MVC's use of the
dependency mechanism could get pretty messy for coordinating 50 views.
It should be possible to design things so that you aren't broadcasting
updates to all the views for each change, but you should think about
this a bit up front.  You probably don't want all 50 views to have the
same model, or you'll spend forever waiting to handle the updates.
The other possible gotcha is that the various algorithms in the window
classes have been optimized for a certain design space, namely a bunch
of fairly simple windows.  If you have scores or hundreds of subviews
in a window you won't be very happy with linear list searches to find
which subview your cursor is pointing to.

Joshua Susser, Object Percussionist
Apple Computer, Advanced Technology Group

Macintosh Jr. - The power to crush the other kids.



Sun, 19 Dec 1993 03:10:36 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. book on MVC triad

2. Sharing code (was: book on MVC triad)

3. using cPickle to store large number of tuples

4. Problems with large numbers using Scotty and Tnm

5. fyi - Web services architecture using MVC style

6. Compile Tcl7.6/Tk4.2 using MVC++5.0

7. US-NC-Triad-Curriculum Developer/Trainer

8. using sizeof do get the number of bytes used by a type

9. PHP Triad Install help PLZ

10. partition a large file into a number of small ones

11. Get large number question

12. dealing with large numbers(?)

 

 
Powered by phpBB® Forum Software