Well for now Andreas patch is fine. It was just a few minor
optimizations which doesn't change the functionality of the code, so
that is cool.
However... this issue is far from solved. Because there is an extension
point there the renderer is vulnerable to somone adding in a very slow
property
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> Sure, but I have no time to put on this. Versioning WFS has been delayed
>> due to 1.5.x release and trunk merge, now I have to work on it full
>> steam.
> Andrea I am not asking for your time - I am asking for your
> consideration of a solution. I
Andrea Aime wrote:
> Sure, but I have no time to put on this. Versioning WFS has been delayed
> due to 1.5.x release and trunk merge, now I have to work on it full
> steam.
Andrea I am not asking for your time - I am asking for your
consideration of a solution. I was unable to tell from this emai
Jody Garnett ha scritto:
> Justin Deoliveira wrote:
>> 1. By not processing the extension point, and not picking up the slow
>> xpath processing property accessor. Instantiate a fast processor and
>> just use it.
> You would need to look at the expression and confirm that xpath was not
> used. Y
Justin Deoliveira wrote:
> 1. By not processing the extension point, and not picking up the slow
> xpath processing property accessor. Instantiate a fast processor and
> just use it.
You would need to look at the expression and confirm that xpath was not
used. You are performing the check once -
Justin Deoliveira ha scritto:
> Andrea Aime wrote:
>>
>> Justin, please, have a look at the changes I committed, and tell me
>> which ones really needed a discussion. Have we to require permission
>> for every trivial change we make? I did modify only the inner workings
>> of a few classes.
>>
> T
Andrea Aime wrote:
>
> Justin, please, have a look at the changes I committed, and tell me
> which ones really needed a discussion. Have we to require permission
> for every trivial change we make? I did modify only the inner workings
> of a few classes.
>
The original point was not that the cha
Justin Deoliveira ha scritto:
> Andrea Aime wrote:
>
>> I was so upset with the obvious disregard of the most basics performance
>> considerations that went and fix without thinking. I have spent days and
>> nights on performance tuning of the streaming renderer, and now these
>> changes blew up
Andrea Aime wrote:
> I was so upset with the obvious disregard of the most basics performance
> considerations that went and fix without thinking. I have spent days and
> nights on performance tuning of the streaming renderer, and now these
> changes blew up my work and make me do more in order t
Andrea Aime wrote:
>
> I'm a little lost here. How do you address performance by using property
> accessors? You seem to imply the work is unfinished, and the stuff that
> could help performance is missing. So, what is that we're missing?
Two possibilities.
1. By not processing the extension p
Paul Ramsey ha scritto:
> Perhaps I am misunderstanding the example from the users list, but the
> changes to property access for wfs1.1 seem to have affected normal
> renderer use, which is why the user ran across the problem.
>
> I was going to ask a completely orthogonal question: there are a
Rob Atkinson ha scritto:
> Good points Justin, Paul etc
>
> Without any of {correct, useful, fast, reliable and maintainable}
> behaviour, there is failure.
>
> There are several requirements out in the wild:
>
> 1) point of truth - make sure you can deliver to the main infrastructure
> someth
Andrea Aime ha scritto:
> Andrea Aime ha scritto:
> An interesting note is that the same rendering code you
> can get on the user mailing list now takes:
> * 24 seconds on jdk 1.4
> * 5.2 seconds on jdk 1.5
> * 3.8 seconds on jdk 1.6
I just backported one of the changes to 2.3.x, since also
2.3.x
Justin Deoliveira ha scritto:
> Thanks for the input Simone.
>
> Perhaps I can clarify something. The property access stuff was *not*
> designed to ignore performance, quite the contrary. It is a level of
> indirection that was added to allow multiple concerns to be addressed,
> one major one b
Justin Deoliveira ha scritto:
> Hi Andrea,
>
> I am kind of puzzled why I am not seeing any patches for any of this, or
> at least a wait for some feedback. This is pretty core stuff you are
> changing, and I would like a chance to comment on it before it gets
> committed. I believe this was pa
8
---
- Original Message -
From: "Justin Deoliveira" <[EMAIL PROTECTED]>
To: "Andrea Aime" <[EMAIL PROTECTED]>
Cc: "Jody Garnett" <[EMAIL PROTECTED]>; "Geotools-Devel list"
Sent: M
Good points Justin, Paul etc
Without any of {correct, useful, fast, reliable and maintainable}
behaviour, there is failure.
There are several requirements out in the wild:
1) point of truth - make sure you can deliver to the main infrastructure
something they can trust. This requires correctne
gt; President/CEO GeoSolutions
> http://www.geo-solutions.it
> Via Carignoni 51
> 550141 Camaiore (LU)
> Italy
> Mobile: +39 333 81 28928
> -------------------
> - Original Message -
> From: "Justin Deoliveira" <[EMA
Fair enough, some good points Paul. Focusing on performance is
definitely a major concern as its one of the things that the end users
actually sees.
I am not surprised that this has risen as an issue as geotools 2.4 has
just begun to go through "release qa". Now is the time to focus on
perform
28
---
- Original Message -
From: "Justin Deoliveira" <[EMAIL PROTECTED]>
To: "Andrea Aime" <[EMAIL PROTECTED]>
Cc: "Jody Garnett" <[EMAIL PROTECTED]>; "Geotools-Devel list"
Sent: M
Perhaps I am misunderstanding the example from the users list, but
the changes to property access for wfs1.1 seem to have affected
normal renderer use, which is why the user ran across the problem.
I was going to ask a completely orthogonal question: there are all
sorts of test cases floatin
Hi Andrea,
I am kind of puzzled why I am not seeing any patches for any of this, or
at least a wait for some feedback. This is pretty core stuff you are
changing, and I would like a chance to comment on it before it gets
committed. I believe this was part of the new process we agreed on, no?
I
Andrea Aime ha scritto:
> History goes on,
> fixed the two above, rendering time is down to 40 seconds
> on java 1.4 and 6 seconds on java 1.5, which makes me think
> we're allocating too many objects ... investigating...
Oh well, I don't really know how to improve it more by quick
tricks, some de
History goes on,
fixed the two above, rendering time is down to 40 seconds
on java 1.4 and 6 seconds on java 1.5, which makes me think
we're allocating too many objects ... investigating...
Cheers
Andrea
-
Using Tomcat but nee
Well,
added the cache, down to 40 seconds. Where are those 40 seconds
spent? Creating property accessors, and trying to convert a Double
to double/float going thru a String object!
Don't you believe me? See:
private float evalToFloat(Expression exp, Object f, float fallback){
if(exp == nu
Hi all,
as you may have noticed, a user recently pointed out very poor
performance while rendering 10 points, something as slow
as 200 seconds. I can confirm the order of magnitude of the
issue, and happily, that's something trunk specific.
A quick profile on only 2500 points shows that Proper
26 matches
Mail list logo
