Re: Object creation overhead
From: Anthony Borla (ajborla_at_bigpond.com)
Date: 11/27/03
- Next message: Richard: "Re: Object creation overhead"
- Previous message: Anthony Borla: "Re: How to determine Java bytecode version"
- In reply to: Richard: "Object creation overhead"
- Next in thread: Richard: "Re: Object creation overhead"
- Reply: Richard: "Re: Object creation overhead"
- Reply: nos: "Re: Object creation overhead"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 26 Nov 2003 23:43:11 GMT
"Richard" <richard@praxistech.com> wrote in message
news:PW5xb.174421$jy.168107@clgrps13...
>
> Hi all,
>
> I am looking for some help on understanding the overhead
> associated with object creation in Java.
>
> I am writing an application where I have written a class to
> encapsulate some text data.
>
> The class is contains these private variables:
>
> // private variables
> private String id = null;
> private String subject = null;
> private String from = null;
> private String date = null;
> private String bytes = null;
> private String lines = null ;
> private boolean isread;
> private String server = null;
> private int port;
> private String group = null;
>
>
> Now I create each object with no parameters passed into
> the constructor, and manually populate 6 of the String variables
> indicated above. Also the server, port and group variables are
> populated for each object instance.
>
> Of course there are accessor methods to deal with accessing
> the private variables, in total about 29 methods for this class.
> The Class implements Serializable and Comparable.
>
<SNIP>
>
> Any suggestions on how to reduce the memory footprint of
> this class?
>
General approaches:
* Reduce the size of each object
- Use 'proxy' objects to represent each 'real' object.
When the proxy is selected, the 'real' object is
instantiated from data stored elsewhere [e.g. in
a database, file, or cache]
- Minimise the number of fields in each object. For
example, instead of using separate 'String' objects
to store data such as 'subject', 'from', etc, just use a
single 'StringBuffer' to hold *all* this data, and
extract it from the 'StringBuffer' via accessors.
The 'StringBufferReader/Writer' classes could help
here
- Use alternate means to represent object data. For
example, instead of pbjects like 'String', encode data
in 'int' primitives and decode using bitwise operations
via accessors
* Reduce the number of objects in memory at the same
time, something that will, of course, require a redesign.
Not knowing your requirements prevents a detailed
response, but here are a few ideas:
- Adopt a database approach i.e. objects stored
externally and only retrieved on demand [probably
not feasable for you, but I thought I'd mention it :)]
- Use a some sort of caching system e.g. keep only
frequently accessed items in memory, etc
- If needing to process the whole chunk of objects
alter your algorithms to work on subsets ata a time
In general, I'd question the need to keep that many objects in memory [but
of course I don't know your requirements]. Hopefully, though, you now have a
few ideas to consider.
>
> p.s. in a similar app written in c++, the same List consumes
> about 18MB, and I am trying to get a similar memory footprint
> as this....
>
Not surprising since there is no JVM and library routines to load into
memory :) !
I hope this helps.
Anthony Borla
- Next message: Richard: "Re: Object creation overhead"
- Previous message: Anthony Borla: "Re: How to determine Java bytecode version"
- In reply to: Richard: "Object creation overhead"
- Next in thread: Richard: "Re: Object creation overhead"
- Reply: Richard: "Re: Object creation overhead"
- Reply: nos: "Re: Object creation overhead"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|