Login | Register
My pages Projects Community openCollabNet

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

gef
Discussion topic

Hide all messages in topic

All messages in topic

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

Reply

Author bob dot tarling at ntlworld dot com
Full name bob dot tarling at ntlworld dot com
Date 2004-01-14 05:33:35 PST
Message >Instead of providing both in the same interface, you could also provide
>a simple adapter class.

Agreed. That makes sense to me.

Assuming the internal child figs eventually remove to arrays then the user wopuld be pushed towards using the most efficient interface.

If I don't get any further input then I'll add an issue along those lines.

--------------------​--------------------​-
Email provided by http://www.ntlhome.com/



--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
For additional commands, e-mail: dev-help at gef dot tigris dot org

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

Reply

Author ipreuss
Full name Ilja Preuß
Date 2004-01-14 04:59:23 PST
Message Bob Tarling wrote:

> I'm drifting towards the idea of absolute encapsulation by
> just having getFig(int), getFigCount(), getFigPosition(Fig),
> addFig(Fig), removeFig(Fig) methods and not returning any arrays or
> collections.
>
> However I think that so many people are used to dealing with
> arrays and Collections and would prefer a smaller API to give them
> such known objects.
>
> Also that so many other API's take arrays or Collections as
> arguments that they may be more convenient objects to pass to other
> systems.
>
> So I'm not yet agreeing or disagreeing with you I'm still wavering.

I'd certainly prefer the more specific API than handling
arrays/collections.


> Maybe I can do both but the JavaDoc must make the user aware
> that "Fig[] getFigs()" returns a copy not not actual
> instance. So if they want absolute performance they should use the
> other access methods.

Instead of providing both in the same interface, you could also provide
a simple adapter class.

Take care, Ilja


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
For additional commands, e-mail: dev-help at gef dot tigris dot org

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 15:30:26 PST
Message Message>Iterators are only bad when they're the only way to iterate. Usually
you can also iterate by asking for the size and using indexed access, i.e.
getChildCount() and >getChild(int). Adding getChildIterator will make some
kinds of iterations easier, since the iterator can be passed to and returned
from methods (the main >advantage of encapsulating state in an object).
The standard Iterators returned from Collections are not that good at
encapsulation. They contain a remove method which could be used to remove a
child fig without GEF being aware. So I would either have to create my own
specialist Iterator that throw an exception on remove or return a copy of
the collection to be sure of encapsulation. At the moment GEF is moving
towards returning copies of collections.

I don't like the idea of throwing an exception on remove. I'd rather be
typesafe at compile time rather than throw an exception on what is not
obvious misuse.

I'm drifting towards the idea of absolute encapsulation by just having
getFig(int), getFigCount(), getFigPosition(Fig), addFig(Fig), removeFig(Fig)
methods and not returning any arrays or collections.

However I think that so many people are used to dealing with arrays and
Collections and would prefer a smaller API to give them such known objects.

Also that so many other API's take arrays or Collections as arguments that
they may be more convenient objects to pass to other systems.

So I'm not yet agreeing or disagreeing with you I'm still wavering.

Maybe I can do both but the JavaDoc must make the user aware that "Fig[]
getFigs()" returns a copy not not actual instance. So if they want absolute
performance they should use the other access methods.

Bob.


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe at gef dot tigris dot org
For additional commands, e-mail: dev-help at gef dot tigris dot org

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

Reply

Author hallvard
Full name Hallvard Trætteberg
Date 2004-01-11 12:24:15 PST
Message Bob,

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

Iterators are only bad when they're the only way to iterate. Usually you
can also iterate by asking for the size and using indexed access, i.e.
getChildCount() and getChild(int). Adding getChildIterator will make
some kinds of iterations easier, since the iterator can be passed to and
returned from methods (the main advantage of encapsulating state in an
object).

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.
 

Type safety should be enforced by the API, not necessarily by the
underlying storage mechanism. You are not thinking of returning the
array itself from any methods are you? Similarly, you can use a List
underneath, while not allowing direct access to it, instead use
getChildCount and getChild (you'll also want getChildPosition() etc.).

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.

If you must return a list, you must ensure that it is not modified
incorrectly.
 
Hallvard
Attachments

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

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

Reply

Author hallvard
Full name Hallvard Trætteberg
Date 2004-01-11 11:26:50 PST
Message 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> 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

[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:08:30 PST
Message 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
Messages per page: