On Aug 9, 2007, at 19:00, Andreas L Delmelle wrote:
On Aug 8, 2007, at 08:30, Manuel Mall wrote:
Not quite my point. When you put your private implementation of an
int
HashMap forward there were concerns raised about this as hard to
maintain and not really required. Now we have a custom im
On Aug 8, 2007, at 08:30, Manuel Mall wrote:
Not quite my point. When you put your private implementation of an int
HashMap forward there were concerns raised about this as hard to
maintain and not really required. Now we have a custom implementation
of a concurrent hash map. Same concerns appl
On Wednesday 08 August 2007 04:02, Andreas L Delmelle wrote:
> On Aug 4, 2007, at 13:22, Vincent Hennebert wrote:
> > Manuel Mall a écrit :
> >
> >
> >> I have been following this discussion with very little attempt to
> >> understand the intricate technical details of concurrent maps etc,
> >> bu
On Aug 4, 2007, at 13:22, Vincent Hennebert wrote:
Manuel Mall a écrit :
I have been following this discussion with very little attempt to
understand the intricate technical details of concurrent maps etc,
but
I am wondering why we don't apply the KISS principle here?
Oh, but it is Simple
Hi,
Manuel Mall a écrit :
> I have been following this discussion with very little attempt to
> understand the intricate technical details of concurrent maps etc, but
> I am wondering why we don't apply the KISS principle here?
>
> IIRC the original problem was that the FOP memory footprint for
>
On Friday 03 August 2007 07:01, Andreas L Delmelle wrote:
> On Aug 1, 2007, at 10:06, Manuel Mall wrote:
> > On Wednesday 01 August 2007 15:45,
> > [EMAIL PROTECTED]
> >
> > What am I missing?
>
> You are not missing anything, AFAICT except that:
> ... FOP still aims for 1.4 compliance
> ... java.u
On Aug 1, 2007, at 10:06, Manuel Mall wrote:
On Wednesday 01 August 2007 15:45, [EMAIL PROTECTED]
What am I missing?
You are not missing anything, AFAICT except that:
... FOP still aims for 1.4 compliance
... java.util.concurrent and like classes have not been implemented
under 1.4 yet...
On Wednesday 01 August 2007 15:45, [EMAIL PROTECTED]
wrote:
> Andreas L Delmelle writes:
> > I've been playing with trying to make the cache thread-local
>
> If in doubt, you could always make the caching multi-level.
> L1 is the current global cache. L2 is a thread-local equivalent
> of the sam
Andreas L Delmelle writes:
> Been reading up a bit on concurrency and synchronization and the
> likes, and I'm in the meantime quite convinced that the strategy
> should indeed be altered to move away from static final Maps. Don't
> know if Richard is still listening in and has any opinio
Andreas L Delmelle wrote:
The CommonBorderPaddingBackground is still a memory eater, but I'll have
to take a look at LengthRangeProperty and CondLengthProperty first for
that.
The trick is probably to split it BPBs in a set of
"specified data" which can be cached and the "resolved
data".
Anot
On Jul 28, 2007, at 17:21, Andreas L Delmelle wrote:
FWIW: I just couldn't resist extending further upon the cache, and in
the meantime I have locally implemented similar caching for
CommonHyphenation (already proposed last week), CommonFont and
KeepProperty.
For CommonFont, since font-
On Jul 25, 2007, at 00:51, Andreas L Delmelle wrote:
Without doing any measurements, one can't say for certain, but I'm
guessing the risk of thread contention is reasonably high.
Already did a few measurements, albeit no real FOP-related tests, but
purely focused on the concurrency behavior
On Jul 25, 2007, at 00:51, Andreas L Delmelle wrote:
Hi all
One more idea before I go to bed:
In the meantime, I'll see if I can think up some tests/timings and
make them part of the build. Jeremias wants to measure this for the
past evolution, and I'd like to make it easier for us to
Hi all
Been reading up a bit on concurrency and synchronization and the
likes, and I'm in the meantime quite convinced that the strategy
should indeed be altered to move away from static final Maps. Don't
know if Richard is still listening in and has any opinions/ideas?
Without doing an
14 matches
Mail list logo
