I've been doing some more work on my FeatureCache implementation. I am
currently designing a "buffer" that will hold a set number of features from
the feature cache in memory. This will increase performance when a user is
working with the same small group of features. The maximum number of
feature
Hi,
Did you have a look to java 5 documentation ? : you'll find interesting
information in Queue interface and LinkedList implementation.
I think there are also many open-source projects related to Cache
management.
With java 5 generics cast is no more necessary.
My advices :
- read the javadoc
Hi Sunburned,
Michaël is correct. It is time to embrace the Java 5 enhancements. It
may even be time to start considering Java 6. My testing shows no problems
with compatibility.
Regarding specific suggestions, I'm afraid I haven't yet understood
exactly what problem you are trying to solve
Michael and Larry,
Thank you for the responses. Please see my comments below.
Michael wrote: "Did you have a look to java 5 documentation ? : you'll find
interesting
information in Queue interface and LinkedList implementation."
Yes, I took a look at the Queue interface. It had the First-In-Fir
The best advice I can give on optimization is never do it until you have
working code. I have been working on JUMP for three years and have only
started looking at optimization the last month or so.
See http://www.extremeprogramming.org/rules/optimize.html
When I said I didn't understand what pr
I misunderstood your response Larry. I apologize about that. I suppose I can
always test the 3 different options for my implementation, but that would be
a lot of work. :] I thought some of the developers would have an idea on
which technique might be the fastest.
If we decide to move to a JDK th
> Yes, I took a look at the Queue interface. It had the
> First-In-First-Out behavior, but I didn't see a way to limit the
> growth of the content, which I would need to do for my purposes. If we
> decide to make the JUMP to a newer JDK version that supports generics
> I might take a look at t
Thanks Michael. I'll take a quick look at some of the libraries you
mentioned.
I'll also have a look at the API documentation for LinkedHashMap.
The Sunburned Surveyor
On 4/13/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
> Yes, I took a look at the Queue interface. It had the
> First-In-F
Michael,
I took a look at the Javadoc for LinkedHashMap. Of particular interest was
the removeEldestEntry() method. I think this was exactly what I needed.
Thank you for your help.
The Sunburned Surveyor
On 4/13/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
Thanks Michael. I'll take a q
Hi Sunburned,
I have the same problem: OpenJUMP chokes when I try to read in the parcels
layer for my country. Even road's layer. I live in Brazil, and shapefile's
size is a problem! :-)
I think overcome the RAM limitation on the size of spatial data sets that
OpenJUMP can import and work with i
Hi guys,
In my laboratory we are working on the memory limitation. It will be
resolved in one month.
Currently we define a new pipeline for datasources access (write and read).
In few days a web page will be available with the documentation and the
design architecture.
See u
R1.
--
Ingénieur
Larry Becker schrieb:
> The best advice I can give on optimization is never do it until you have
> working code. I have been working on JUMP for three years and have only
> started looking at optimization the last month or so.
>
> See http://www.extremeprogramming.org/rules/optimize.html
whi
Juliana,
I'm not sure if you have posted to the mailing list before. If you haven't I
want to extend you a warm welcome. If you have, please forgive me for my
faulty memory.
It sounds like we will have a solution to the memory problem in OpenJUMP
very soon! This is good news for you and I. :]
E
Hei Landon, with respect to your questions to Erwan
please have also a look on the google-doc document.
As far as i know you were one of the persons having acceess to it ... In
that doc is a very brief sketch of the system.
otherwise i send you a copy of the doc
stefan
Sunburned Surveyor schri
14 matches
Mail list logo
