Re: Caching CommonHyphenation (was: Re: The effect of the property cache ...)
On Jul 20, 2007, at 09:19, Jeremias Maerki wrote:
This means we currently end up in the strange situation where
different/separate CommonHyphenation instances are generated from
identical sets of base Property instances.
Raises the question for me if for properties without dynamic
context-based
evaluation the property evaluation could be streamlined to directly
return the primitive values instead of simple container objects like
NumberProperty. throw new NotEnoughTimeRightNowException();
The 'evaluation' here is precisely triggered by the calls to
PropertyList.get().
Before those calls in the CommonHyphenation constructor, the base
properties might not even exist yet (if they were not specified on
the FO that is bound to the CommonHyphenation).
Trading the NumberProperty for an int... No idea if that's feasible
without a thorough revision. The entire property resolution mechanism
currently depends on the generic Property return type. That design
would obviously have to be abandoned for this handful of cases...
public boolean hyphenate() {
return (hyphenate.getEnum() == EN_TRUE);
Well, I'd prefer Bean-style getters, i.e. getLanguage(),
isHyphenationEnabled()
No problem. That was only by means of an example.
Opinions?
For the interested parties: full CommonHyphenation below, following
roughly the same principles as the Property caching.
"hash" should probably be transient here because it's a cached value.
Checked this out, and transient seems to be only applicable in a
serialization context. If the object is never serialized, adding that
keyword would seem to have zero effect... unless I'm missing something.
Cheers
Andreas
Re: Caching CommonHyphenation (was: Re: The effect of the property cache ...)
On 20.07.2007 06:56:21 Andreas L Delmelle wrote:
> On Jul 19, 2007, at 00:36, Andreas L Delmelle wrote:
>
> >
> > On Jul 18, 2007, at 23:18, Jeremias Maerki wrote:
> >
> >> - One of the easiest candidates for another flyweight is probably
> >> CommonHyphenation (56K instances, 2.3MB in my example). The few
> >> member
> >> variables could probably just be concatenated to a String (to be
> >> used as
> >> the key).
> >
> > Interesting idea, will look into that asap.
>
> FWIW:
> Looked a bit closer at this, and it suddenly struck me that all the
> base Property types, apart from CharacterProperty which I overlooked
> as a possible candidate, were already cached:
>
> StringProperty -> language, country, script
> NumberProperty -> hyphenation-push/remain-character-count
> EnumProperty -> hyphenate
>
> CharacterProperty(*) -> hyphenation-character
>
> (*) now also added, see http://svn.apache.org/viewvc?view=rev&rev=557814
>
> This means we currently end up in the strange situation where
> different/separate CommonHyphenation instances are generated from
> identical sets of base Property instances.
Raises the question for me if for properties without dynamic context-based
evaluation the property evaluation could be streamlined to directly
return the primitive values instead of simple container objects like
NumberProperty. throw new NotEnoughTimeRightNowException();
> Maybe the CommonHyphenation bundle could store references to the
> original properties themselves instead of duplicating their content/
> value and storing them as primitives? By itself, this should be
> roughly the same in terms of overall memory consumption: replacement
> of some primitives with references.
>
> In that case, one of the additional benefits of the individual
> Property caching is that you can now actually avoid calls to
> StringProperty.equals() in the rest of the code. "identity" means the
> same as "equality" here, so the fastest possible implementation for
> CommonHyphenation.equals() would then come to look like:
>
> public final class CommonHyphenation {
> ...
> public final StringProperty language;
> public final StringProperty script;
> public final StringProperty country;
> public final EnumProperty hyphenate;
> ...
> public boolean equals(Object obj) {
>if (obj == this) {
> return true;
>}
>if (obj instanceof CommonHyphenation) {
> CommonHyphenation ch = (CommonHyphenation) obj;
> return (ch.language == this.language
> && ch.script == this.script
> && ch.country == this.country
> && ch.hyphenate == this.hyphenate
> && ...)
>}
>return false;
> }
>
> One thing that cannot be avoided is the multiple calls to
> PropertyList.get() to get to the properties that are needed to
> perform the check for a flyweight bundle. Maybe the initial
> assignments can be moved into the getInstance() method, so they
> become part of the static code. getInstance() would get a
> PropertyList as argument, while the private constructor signature is
> altered to accept all the base properties as parameters.
>
> The key in the Map could be a composite String, but could also again
> be the CommonHyphenation itself, if a decent hashCode()
> implementation is added.
> The benefit of using the instance itself is that the key in a
> WeakHashMap is automatically released after the last object referring
> to it has been cleared. Using a key other than the instance itself
> would make WeakHashMap unusable, since the keys are in that case not
> referenced directly by any object. The key cannot be embedded in the
> instance itself, since that would prevent the entire entry from ever
> being released...
>
> The properties themselves being immutable and final, I guess it does
> no harm to expose them as public members. Only a handful of places in
> TextLM and LineLM would need a slight adjustment to compensate for
> the lost getString() and getEnum() conversions. Maybe for
> convenience, if really needed, accessors could be added like:
>
> public String language() {
>return language.getString();
> }
> ...
> public boolean hyphenate() {
>return (hyphenate.getEnum() == EN_TRUE);
Well, I'd prefer Bean-style getters, i.e. getLanguage(),
isHyphenationEnabled()
>
> Opinions?
> For the interested parties: full CommonHyphenation below, following
> roughly the same principles as the Property caching.
"hash" should probably be transient here because it's a cached value.
> Cheers
>
> Andreas
>
> --- Sample code ---
> public final class CommonHyphenation {
>
> private static final Map cache =
> java.util.Collections.synchronizedMap(
> new java.util.WeakHashMap());
>
> private int hash = 0;
>
> /** The "language" property */
> private final StringProperty language;
>
> /** The "country" property */
> private final StringProperty co
Caching CommonHyphenation (was: Re: The effect of the property cache ...)
On Jul 19, 2007, at 00:36, Andreas L Delmelle wrote:
On Jul 18, 2007, at 23:18, Jeremias Maerki wrote:
- One of the easiest candidates for another flyweight is probably
CommonHyphenation (56K instances, 2.3MB in my example). The few
member
variables could probably just be concatenated to a String (to be
used as
the key).
Interesting idea, will look into that asap.
FWIW:
Looked a bit closer at this, and it suddenly struck me that all the
base Property types, apart from CharacterProperty which I overlooked
as a possible candidate, were already cached:
StringProperty -> language, country, script
NumberProperty -> hyphenation-push/remain-character-count
EnumProperty -> hyphenate
CharacterProperty(*) -> hyphenation-character
(*) now also added, see http://svn.apache.org/viewvc?view=rev&rev=557814
This means we currently end up in the strange situation where
different/separate CommonHyphenation instances are generated from
identical sets of base Property instances.
Maybe the CommonHyphenation bundle could store references to the
original properties themselves instead of duplicating their content/
value and storing them as primitives? By itself, this should be
roughly the same in terms of overall memory consumption: replacement
of some primitives with references.
In that case, one of the additional benefits of the individual
Property caching is that you can now actually avoid calls to
StringProperty.equals() in the rest of the code. "identity" means the
same as "equality" here, so the fastest possible implementation for
CommonHyphenation.equals() would then come to look like:
public final class CommonHyphenation {
...
public final StringProperty language;
public final StringProperty script;
public final StringProperty country;
public final EnumProperty hyphenate;
...
public boolean equals(Object obj) {
if (obj == this) {
return true;
}
if (obj instanceof CommonHyphenation) {
CommonHyphenation ch = (CommonHyphenation) obj;
return (ch.language == this.language
&& ch.script == this.script
&& ch.country == this.country
&& ch.hyphenate == this.hyphenate
&& ...)
}
return false;
}
One thing that cannot be avoided is the multiple calls to
PropertyList.get() to get to the properties that are needed to
perform the check for a flyweight bundle. Maybe the initial
assignments can be moved into the getInstance() method, so they
become part of the static code. getInstance() would get a
PropertyList as argument, while the private constructor signature is
altered to accept all the base properties as parameters.
The key in the Map could be a composite String, but could also again
be the CommonHyphenation itself, if a decent hashCode()
implementation is added.
The benefit of using the instance itself is that the key in a
WeakHashMap is automatically released after the last object referring
to it has been cleared. Using a key other than the instance itself
would make WeakHashMap unusable, since the keys are in that case not
referenced directly by any object. The key cannot be embedded in the
instance itself, since that would prevent the entire entry from ever
being released...
The properties themselves being immutable and final, I guess it does
no harm to expose them as public members. Only a handful of places in
TextLM and LineLM would need a slight adjustment to compensate for
the lost getString() and getEnum() conversions. Maybe for
convenience, if really needed, accessors could be added like:
public String language() {
return language.getString();
}
...
public boolean hyphenate() {
return (hyphenate.getEnum() == EN_TRUE);
Opinions?
For the interested parties: full CommonHyphenation below, following
roughly the same principles as the Property caching.
Cheers
Andreas
--- Sample code ---
public final class CommonHyphenation {
private static final Map cache =
java.util.Collections.synchronizedMap(
new java.util.WeakHashMap());
private int hash = 0;
/** The "language" property */
private final StringProperty language;
/** The "country" property */
private final StringProperty country;
/** The "script" property */
private final StringProperty script;
/** The "hyphenate" property */
private final EnumProperty hyphenate;
/** The "hyphenation-character" property */
private final CharacterProperty hyphenationCharacter;
/** The "hyphenation-push-character-count" property */
private final NumberProperty hyphenationPushCharacterCount;
/** The "hyphenation-remain-character-count" property*/
private final NumberProperty hyphenationRemainCharacterCount;
/**
* Construct a CommonHyphenation object holding the given
properties
*
*/
private CommonHyphenation(StringProperty language,
StringProperty country,
