commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [classscan] Metadata API discussion
Date Thu, 07 Jun 2012 07:56:05 GMT
On 7 June 2012 05:18, Mark Struberg <struberg@yahoo.de> wrote:
>> You mention that interfaces take a bit more space in memory.  Is this
>> because there is an adapter class (implementing the interface) and the
>> delegated final implementor? Or are you pointing out some other memory
>> concern?
> It's not much actually. Merely 80 bytes + fully qualified class name length. But we have
100.000s of instances. That might sum up. We need to trace it finally. Otherwise +1 for interfaces.
>

Not sure I follow this. Why would an interface use extra memory?
I can see that it might add a bit more to the static size of a class,
but why would it add more to each instance of a class that uses it?

>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: "Honton, Charles" <Charles_Honton@intuit.com>
>> To: Commons Developers List <dev@commons.apache.org>; Mark Struberg <struberg@yahoo.de>
>> Cc:
>> Sent: Thursday, June 7, 2012 1:49 AM
>> Subject: Re: [classscan] Metadata API discussion
>>
>> Mark,
>>
>> In the BCEL implementation I originally used adapter classes which
>> implemented the appropriate interface and delegated to the BCEL object.
>> Unfortunately, this created a large memory footprint.  The BCEL objects
>> are not frugal with memory.
>>
>> I'm pretty sure we could tease apart the BCEL parts from the caching
>> parts.  During that split, we could introduce the scanner SPI.
>>
>> I am a big fan of interfaces.  Interfaces at the SPI would allow
>> techniques such as delayed instantiation, perhaps other flexibility that
>> will be useful.
>>
>> On the other hand, we may find each provider re-implement the same Meta
>> information classes.  We may wish to provide a default immutable
>> implementation for each meta information interface.
>>
>> You mention that interfaces take a bit more space in memory.  Is this
>> because there is an adapter class (implementing the interface) and the
>> delegated final implementor? Or are you pointing out some other memory
>> concern?
>>
>> Chas
>>
>>
>>
>> On 6/6/12 2:37 PM, "Mark Struberg" <struberg@yahoo.de> wrote:
>>
>>> Hi!
>>>
>>> I now did read through the metadata classes of Chas' and Davids impls.
>>>
>>> Both look pretty similar to some degree. A few key differences
>>>
>>> * using AnnotatedElement instead of HasName() makes it possible to
>>> replace most 'old' code which does getAnnotations() etc 1:1
>>>  Imo we should keep this feature.
>>>
>>> * to interface or not to interface, that's the question.
>>>
>>>  The actual meta information should be as small as possible. There are
>>> tons of it.
>>>
>>>  1. Currently in Chas' impl there are bcel specific parts in it. Can
>>> those probably be extracted? I think so, or do you see any problems? If
>>> we cannot split then we should keep the interfaces. But remember that
>>> this takes (a bit) more space in mem.
>>>  2. If Interfaces, then impls could point to bcel/asm internal strutures
>>> for storing the data. This would reduce space. But only if bcel/asm would
>>> keep this info anyway. Otherswise it might be better to throw the
>>> bcel/asm stuff away after repackaging to a small meta info holder.
>>>
>>>
>>>
>>> (just to not loose some questions... more to come...)
>>>
>>> LieGrue,
>>> strub
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message