Re: response time problem.

Frederick Cheung
Thu, 27 Mar 2008 09:26:13 -0000

On 27 Mar 2008, at 08:46, Mukund wrote:

>
> Thanks for mentioning ruby-prof.  I haven''t used a profiler for
Ruby
> before and I like it.   I put the RubyProf.start at the start of the
> controller action and RubyProf.stop at the end of the controller
> action and the results are as expected.
>
>
Well the basic problems is that if your lists are of length m and n
then what you''ve got there has complexity O(mn) (which shows up as the
80 million calls to those functions).
I''d also query the efficiency of any action that results in Mysql
being queried 50000 times. If you stored @availLandmarkList as a hash
rather than as an array you''d avoid the linear time search for every
element of params[:selectedLandmark].

Fred.
> Thread ID: 46912571459280
> Total: 914.720000
>
> %self     total     self     wait    child    calls  name
> 46.31    759.76   423.65     0.05   336.06     8852  Array#select
> (ruby_runtime:0}
> 16.02    146.53   146.53     0.00     0.00 78251690  Fixnum#to_s
> (ruby_runtime:0}
> 10.41     95.22    95.22     0.00     0.00 78243001  Array#[]
> (ruby_runtime:0}
> 10.37     94.89    94.89     0.00     0.00 78252170  String#=>
(ruby_runtime:0}
>  1.94     30.28    17.73     0.14    12.41    53050
> <Module::Benchmark>#realtime (/usr/lib/ruby/1.8/benchmark.rb:306}
>  0.92      8.43     8.43     0.00     0.00  1697290  Kernel#sprintf
> (ruby_runtime:0}
>  0.76     20.79     6.94     0.01    13.84    17680  String#each_byte
> (ruby_runtime:0}
>  0.45      4.23     4.14     0.00     0.09    53050  Mysql#query
> (ruby_runtime:0}
>
> I have fixed the workflow of the application so that I dont end up
> with two lists of 9K each, but if I do end up with two lists of these
> sizes that I need to manage in the future, any other tricks I can use
> or do I need to change data structures and design only?
>
> Thanks,
> Mukund
>
>
>
> On Mar 23, 3:02 am, Frederick Cheung
<frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
>>> --->         params[:selectedLandmark].each { |itr|
>>>          @selectedLandmarkList += @availLandmarkList.select{ |v|
>>> (v[1].to_s==itr)? true : false }
>>>        }
>>>      else ....
>>
>>> If I get rid of the iterator which basically doesn''t do
much, the
>>> response time is fast as the second list is empty. I don''t
>>> understand
>>> why it is slow in the first case.
>>
>> Well you may not think you''re doin very much but for each
thing
>> selectedLandmar you''re iterating over availLandmarkList once,
so if
>> these are both 9000 items long then you''re ending up doing
something
>> 81 million times. But whatever the reason is, the real answer is to
>> stop guessing and use a profiler (eg ruby-prof) to find out where the
>> time is going.
>>
>> Fred
> >