Eliminated the uuid overhead (create them only when needed). We're
down to 2%. Out of which 1% is to get the remote address from the
servlet engine.
http://ws.zones.apache.org/~dims/msg-context-004.png
thanks,
dims
On 2/5/07, David Illsley <[EMAIL PROTECTED]> wrote:
I know what you were worrie
I know what you were worried about... FWIW, I'm worried about the UUID
thing as well.
I'm also worried about the (now) 4% taken setting up transport
information when it's really not clear what's CPU intensive in there
(or that it should be).
David
On 05/02/07, Davanum Srinivas <[EMAIL PROTECTED
Sanjiva,
Hang on!. Am not done reviewing/fixing yet :) need another day or so.
thanks,
dims
On 2/5/07, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
On Sun, 2007-02-04 at 17:43 -0500, Davanum Srinivas wrote:
> Bill,
>
> I just started looking into the perf aspects of this checkin...Here's
> t
On Sun, 2007-02-04 at 17:43 -0500, Davanum Srinivas wrote:
> Bill,
>
> I just started looking into the perf aspects of this checkin...Here's
> the first one. Please see the following 2 images:
>
> http://people.apache.org/~dims/msg-context-001.png
> http://people.apache.org/~dims/msg-context-002.
David,
Latest run (fresh from svn), it's about 4%...It's the getUUID's and
string concat to make the correlation id's. that's what i was talking
about :)
http://ws.zones.apache.org/~dims/msg-context-003.png
-- dims
On 2/5/07, David Illsley <[EMAIL PROTECTED]> wrote:
Hi Dims,
Looking at uuid-0
Hi Dims,
Looking at uuid-001.png,
AxisServlet.createAndSetInitialParamsToMsgCtxt is causing 5% of the
total time which seems a lot for what I thought it was doing. I don't
have a profiler to hand, could you show us a breakdown of what that
method is calling and why it's taking so long?
Cheers,
Da
Here's one more. Proliferation of getUUID's.
http://ws.zones.apache.org/~dims/uuid-001.png
http://ws.zones.apache.org/~dims/uuid-002.png
We used to call getUUID once or at most twice. Now we create 6 uuid's
for each req/resp taking up 1.9% (375/19533 * 100). Please change the
code to create the
Bill,
I just started looking into the perf aspects of this checkin...Here's
the first one. Please see the following 2 images:
http://people.apache.org/~dims/msg-context-001.png
http://people.apache.org/~dims/msg-context-002.png
As you can plainly see, the servlet is called 2500 times, and takes
+1 .. how about doing this just *before* cutting the release branch?
That way if the reformat causes issues it'll get fixed on the branch
(and then merged). Furthermore, when the branch is merged later it will
not appear to change everything .. as a reformat may.
Sanjiva.
On Fri, 2007-02-02 at 1
I think we should also have periodic sweeps where someone uses their IDE
or another tool to do a wholesale reformat of the entire codebase to
match the conventions (this won't fix everything, no, but it can help),
and then checks in ONLY the formatting changes. Maybe right before
releases?
-
Bill,
The same IDE that lets you find things easily, lets you reformat the
code to sun convention too and we have some additional stuff on top of
that which is also usually configurable. Definitely, there is no
excuse for not following the conventions. Yes, if you see something
wrong in someone's
On Thu, 2007-02-01 at 09:57 -0800, Bill Nagy wrote:
>
> I don't honestly think that anyone who we want to be writing code for
> the project would have trouble understanding code simply because braces
> weren't on the lines where they typically put them or that methods
> aren't named in the same wa
Hi Sanjiva,
On Thu, 2007-02-01 at 21:33 +0530, Sanjiva Weerawarana wrote:
> On Thu, 2007-02-01 at 06:10 -0800, Bill Nagy wrote:
> > Hi Rajith,
> >
> > Usage of the serialization is/will be configurable through Sandesha --
> > Matt said that he would be adding code to do that (if it isn't there
>
Subject
Re: [Axis2] Issues with the current
code base
Please respond to
[EMAIL PROTECTED]
On Thu, 2007-02-01 at 06:10 -0800, Bill Nagy wrote:
> Hi Rajith,
>
> Usage of the serialization is/will be configurable through Sandesha --
> Matt said that he would be adding code to do that (if it isn't there
> already.) If the serialization doesn't get invoked, then all that will
> occur will
Hi Rajith,
Usage of the serialization is/will be configurable through Sandesha --
Matt said that he would be adding code to do that (if it isn't there
already.) If the serialization doesn't get invoked, then all that will
occur will be a few no-op method invocations.
I don't agree with point 5 b
I do have one question for Anne, is this serialization configurable ?
In other words can I switch off this behaviour if I don't want it?
(Pardon me for not going through the code to figure this out )
I also share the same concerns as Deepal about code conventions.
No matter what coding convention
HI all,
We already have a document which talks about the code quality [1]. We
can add whatever more details in to there.. We also need a BIG BOLD
lettered link to this page..
We have earlier agreed on using java coding conventions.. But IMHO
It's always implied that a java developer will adhere
FYI : http://wiki.apache.org/ws/FrontPage/Axis2/CodeQuality
Thanks,
Ruchith
On 1/30/07, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
On Mon, 2007-01-29 at 13:37 -0800, Bill Nagy wrote:
>
> I was unable to find them on the wiki (I looked at both the current as
> well as the old root pages.) T
Hi Bill,
>
>>Among the all , the most worst thing I saw in the code is following kind
>>of things, I strongly believe we should not have this kind of code in
>>the code base, If you found such kind of code please point out them then
>>and there.
>>
>> - String tmpClassNameStr = "null"; (is this
On Mon, 2007-01-29 at 13:37 -0800, Bill Nagy wrote:
>
> I was unable to find them on the wiki (I looked at both the current as
> well as the old root pages.) The JAX-WS proposal only speaks in the
> abstract about code organization -- it says nothing about the formatting
> of Java source files.
Hi Sanjiva,
On Mon, 2007-01-29 at 23:42 +0530, Sanjiva Weerawarana wrote:
> Bill, IMO I made a mistake in lifting my -1 on this patch .. this
> could've and should've gone in as an auxiliary bit of code without
> modifying MC at all. Calling mc.activateMessageContext on *every*
> message that come
Bill, IMO I made a mistake in lifting my -1 on this patch .. this
could've and should've gone in as an auxiliary bit of code without
modifying MC at all. Calling mc.activateMessageContext on *every*
message that comes in seems like a major ovehead to the mind even if not
to the body (you know what
Hi Deepal,
On Mon, 2007-01-29 at 11:41 +0530, Deepal Jayasinghe wrote:
> Hi all;
>
> I just went though the current code base and realized that
> MessageContext code has been changed a lot . I found few issues with the
> code base and hope we need to fix them. So I thought of sending this
> mail
Hi all,
Deepal Jayasinghe <[EMAIL PROTECTED]> wrote on 29/01/2007 06:11:47:
> Hi all;
>
> I just went though the current code base and realized that
> MessageContext code has been changed a lot . I found few issues with the
> code base and hope we need to fix them. So I thought of sending this
On 1/29/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
Hi all;
I just went though the current code base and realized that
MessageContext code has been changed a lot . I found few issues with the
code base and hope we need to fix them. So I thought of sending this
mail for everyone's considera
Hi all;
I just went though the current code base and realized that
MessageContext code has been changed a lot . I found few issues with the
code base and hope we need to fix them. So I thought of sending this
mail for everyone's consideration.
Well someone please explain to me whose going to need
27 matches
Mail list logo