Re: [Geotools-gt2-users] =?iso-8859-1?q?R=E9f=2E_=3A_Re=3A__Poor_perf?= =?iso-8859-1?q?ormance_=3D=3FISO-8859-1=3FQ=3F=5Fusing=5FFilter=5Fwith_sh?= =?iso-8859-1?q?apefile=3D2E=3D2E=3D2E=3F=3D?=

[Andrea A. <and...@al...>]

seb...@in... ha scritto:

> Andrea (and everybody),
> 
> Thanks for this response.
> 
> Be sure I've tried this test not on one single line, but on thousands...
> To be more precise, i've made this bench on a task which take up to 2 
> minutes based on shapefile and only 2 seconds with in memory data 
> (really, it isn't a joke!)

I do believe you. Disk access is usually 1000 times slower, and even when
the shapefile is in the file cache, there are still all the decodes needed
to turn shapefile data structures into features, and memory data store does
not need to do anything of these...

> But to be more exact, i am disapoint that I have to clone my shapefile 
> into an "in memory" layer myself and i am not sure to use the right way. 
> I think our famous Udig's mainteners have something else to do that ;o)

Fact is, udig is geared towards data sets that cannot be loaded into memory
at all because they are too big. I think they took into consideration the
idea of preloading data into memory, but it's hard to make it right, because
on jdbc or wfs data stores data can change under your feet without you noticing
(not all data stores support event notifications for data changes afaik, but
I may be mistaken).

Cheers
Andrea Aime