Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (asf.osuosl.org: 204.17.65.6 is neither permitted nor
 denied by domain of dckerber@verizon.net)
Message-ID: <44D778E3.2080204@verizon.net>
Date: Mon, 07 Aug 2006 13:31:15 -0400
From: David Kerber <dckerber@verizon.net>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Code performance question #2
References: <DDBBD1E00935D144AB9563D57EF98D622F7E26@raccoon.melandra.net>
 <44D7729B.6000100@pidster.com>
In-Reply-To: <44D7729B.6000100@pidster.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Pid wrote:

>here's another obvious question:
>
>if you're in a servlet, and you're getting an & separated string from
>somewhere, where is the "somewhere" that you're getting it from?
>
>does the servlet activate and collection the data somehow, or does the
>data get sent to the servlet (in, for example the query string)?
>  
>
The data is sent via an HTTP POST request, with the query string lightly 
encrypted.

>
>
>
>
>Peter Crowther wrote:
>  
>
>>>From: David Kerber [mailto:dckerber@verizon.net] 
>>>Is there a more efficient "split" method I could use?  Or am I 
>>>completely missing the point of what you are suggesting?
>>>      
>>>
>>I think you've slightly missed the point.  I assume you're calling your function 5 times, each with a different field name that you want out of it.  You're then invoking string handling functions on the entire decrypted string 5 times, each time going through the bytes to extract the piece you need.  In the process, you traverse bytes you don't need several times.  My suggestion is that you tokenise this *once*, and hence only pay the string-handling overhead once.  Then you get all the parameters out of the same tokenised version.
>>
>>However, if the next thing you do is to write this to disk, I am even more convinced that you're optimising the wrong piece of code as the disk I/O is likely to take vastly more instructions than the string parse.
>>
>>These may be na�ve questions, but I'll ask them anyway.  How have you identified these two pieces of code as the targets for optimisation?  What profiler have you used, under what conditions?  What proportion of your overall CPU budget is taken by these two snippets of code?  Is the machine CPU-bound in the first place, or is the bottleneck elsewhere?  If these are the worst culprits in your app, I'll be very surprised.
>>
>>		- Peter
>>    
>>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org