Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [gef-dev] Performance suggestion 1 - Arrays

gef
Discussion topic

Back to topic list

Re: [gef-dev] Performance suggestion 1 - Arrays

Reply

Author Bob Tarling <bob dot tarling at ntlworld dot com>
Full name Bob Tarling <bob dot tarling at ntlworld dot com>
Date 2004-01-11 11:44:38 PST
Message Message>you shouldn't start making changing without knowing where the performance problems are
I don't think I'll be doing this in the short term - just thinking out-loud. Once a solution is more fully formed I'll create an issue.
You'll know when I plan to actually do something major by the creation of an issue.

Iterators was one of the reasons I was thinking about move away from Collections.

One of the things I've noticed on the move from Vector to Collection interfaces is that the actual application code now needs to create an iterator to loop through items. If there are loops within loops then this could be a potential drain.

I thought about being more specific on the type of collection and returning Lists instead of Collections. It then seemed to me only one step further to go completely to arrays instead as the advantages are well known. Efficiency and type safety.

Also the problem with iterators is that you cannot find the size. I think better to return a collection or an List and the client coder has the option of how to iterate.

I really need the test app I was describing to test any change properly.

Bob.

  ----- Original Message -----
  From: Hallvard Trætteberg
  To: dev at gef dot tigris dot org
  Sent: Sunday, January 11, 2004 7:26 PM
  Subject: RE: [gef-dev] Performance suggestion 1 - Arrays


  Bob,

  In such a huge package as GEF there will be many possible way so increase performance, but you shouldn't start making changing without knowing where the performance problems are. I don't think moving from Collection to Array storage will affect performance of creation of figs or traversal of children noticeably. However, it will save memory in the long run, which may be important. The only time I've needed to do something similar was i JGraph (a "competitor" to GEF), where I moved from list/point based to array/double based coordinate storage. In this case the number of objects saved was huge, much larger than you'll experience with your change.

  I don't think there's any point in distinguishing between the two cases of fixed or variable length. If you're implementing array-based storage, it's very easy to add support for increasing the size if there too little space. Handling the two different cases of array or list access, will be more complex. To support fixed size child arrays, I would add a protected constructor with a size argument, that's used by subclasses to get the right size and avoid resizing.

  You should perhaps also think of introducing a ChildIterator class (returns a series of Fig children), and get rid of Collection based access all together. This will give you more control of access and make Figs a more complete abstraction.
  Hallvard Trætteberg, 1.amanuensis ved Inst. for datateknikk og informasjonsvitenskap ved NTNU
  www.idi.ntnu.no/~hal, mailto:hal at idi dot ntnu dot no phone:+47 7359 3443,



    -----Original Message-----
    From: Bob Tarling [mailto:bob.tarling@​ntlworld.com]
    Sent: 11. januar 2004 20:09
    To: dev at gef dot tigris dot org
    Subject: [gef-dev] Performance suggestion 1 - Arrays


    I've been thinking about performance issues in GEF and wondering about making GEF more array oriented than Collection oriented, particularly as far as FigGroups are concerned.

    All the FigGroups I've seen in actual applications are of a fixed size so there is no great benefit in storing contents in a collection rather than an array.

    I'm considering making a distinction between those FigGroups that are a fixed size or not. Fixed size figs will use an array as their store and variable sized figs will use an ArrayList.

    I'll probably determine which to create by whether a Fig implements a certain interface. I've previously mentioned a possible interface such as

    FigContainer
        Collection getFigs()
        Fig getFigAt(int i)

    Maybe we should have 2 extensions of this VariableFigContainer and FixedFigContainer

    FixedFigContainer would add no extra methods but act as a trigger to indicate storage by array.
    VariableFigContainer would indicate storage by ArrayList and would enforce the methods like
        void addFig(Fig f);
        void removeFig(Fig f);

    I'd also like a test app put together to test performance issues. Something that will automatically create a graph of a given number of nodes and help with timing drags and so on. I'd like to know that from one release of GEF to the next that we are not adding to any perfomance problems the client app may already have.

    Bob.
Attachments

« Previous message in topic | 3 of 7 | Next message in topic »

Messages

Show all messages in topic

[gef-dev] Performance suggestion 1 - Arrays Bob Tarling <bob dot tarling at ntlworld dot com> Bob Tarling <bob dot tarling at ntlworld dot com> 2004-01-11 11:08:30 PST
     RE: [gef-dev] Performance suggestion 1 - Arrays hallvard Hallvard Trætteberg 2004-01-11 11:26:50 PST
         Re: [gef-dev] Performance suggestion 1 - Arrays Bob Tarling <bob dot tarling at ntlworld dot com> Bob Tarling <bob dot tarling at ntlworld dot com> 2004-01-11 11:44:38 PST
             RE: [gef-dev] Performance suggestion 1 - Arrays hallvard Hallvard Trætteberg 2004-01-11 12:24:15 PST
                 Re: [gef-dev] Performance suggestion 1 - Arrays Bob Tarling <bob dot tarling at ntlworld dot com> Bob Tarling <bob dot tarling at ntlworld dot com> 2004-01-11 15:30:26 PST
                     RE: [gef-dev] Performance suggestion 1 - Arrays ipreuss Ilja Preuß 2004-01-14 04:59:23 PST
                         Re: RE: [gef-dev] Performance suggestion 1 - Arrays bob dot tarling at ntlworld dot com bob dot tarling at ntlworld dot com 2004-01-14 05:33:35 PST
Messages per page: