On 7 June 2012 05:18, Mark Struberg <strub...@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_hon...@intuit.com> >> To: Commons Developers List <dev@commons.apache.org>; Mark Struberg >> <strub...@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" <strub...@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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
