From fab71932702515038c05f7b3097784ebe7d47fe7 Mon Sep 17 00:00:00 2001 From: Alan DaCosta Date: Thu, 6 Nov 2008 08:05:04 -0800 Subject: [PATCH] Fix guide typos --- .../benchmarking_and_profiling/digging_deeper.txt | 6 +++--- .../source/benchmarking_and_profiling/gameplan.txt | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/railties/doc/guides/source/benchmarking_and_profiling/digging_deeper.txt b/railties/doc/guides/source/benchmarking_and_profiling/digging_deeper.txt index fe22fba..7ddab6e 100644 --- a/railties/doc/guides/source/benchmarking_and_profiling/digging_deeper.txt +++ b/railties/doc/guides/source/benchmarking_and_profiling/digging_deeper.txt @@ -51,7 +51,7 @@ that over a factor of ten difference. Lets look at our flat process time file to Yes indeed we seem to have found the problem. Pathname#cleanpath_aggressive is taking nearly a quarter our process time and Pathname#chop_basename another 17%. From here I do a few more benchmarks to make sure that these processes are slowing down the other pages. They are so now I know what I must do. *If we can get rid of or shorten these processes we can make our pages run much quicker*. -Now both of these are main ruby processes so are goal right now is to find out what other process is calling them. Glancing at our Graph file I see that #cleanpath is calling #cleanpath_aggressive. #cleanpath is being called by String#gsub and from there some html template errors. But my page seems to be rendering fine. why would it be calling template errors. I'm decide to check my object flat file to see if I can find any more information. +Now both of these are main ruby processes so are goal right now is to find out what other process is calling them. Glancing at our Graph file I see that #cleanpath is calling #cleanpath_aggressive. #cleanpath is being called by String#gsub and from there some html template errors. My page seems to be rendering fine. Why would it be calling template errors? I'll check my object flat file to see if I can find any more information. .Objects Created ---------------------------------------------------------------------------- @@ -62,7 +62,7 @@ Now both of these are main ruby processes so are goal right now is to find out w 6.07 3606.00 3606.00 0.00 0.00 3606 Regexp#to_s ---------------------------------------------------------------------------- -nope nothing new here. Lets look at memory usage +Nope nothing new here. Lets look at memory usage .Memory Consuption ---------------------------------------------------------------------------- @@ -101,5 +101,5 @@ process_time: 75 ms objects: 6537 ---------------------------------------------------------------------------- -Much better. The problem has been solved. Now I should have realized earlier due to the String#gsub that my problem had to be with reqexp serch function but such knowledge comes with time. Looking through the mass output data is a skill. +Much better. The problem has been solved. Now I should have realized earlier due to the String#gsub that my problem had to be with regexp serch function but such knowledge comes with time. Looking through the mass output data is a skill. diff --git a/railties/doc/guides/source/benchmarking_and_profiling/gameplan.txt b/railties/doc/guides/source/benchmarking_and_profiling/gameplan.txt index 1f1d365..a6a5d41 100644 --- a/railties/doc/guides/source/benchmarking_and_profiling/gameplan.txt +++ b/railties/doc/guides/source/benchmarking_and_profiling/gameplan.txt @@ -14,8 +14,8 @@ Formulate a question you need to answer which is simple, tests the smallest meas * Profile based on the question and variables. Key problems to avoid when designing this experiment are: - Confounding: Test one thing at a time, keep everything the same so you don't poison the data with uncontrolled processes. - Cross Contamination: Make sure that runs from one test do not harm the other tests. - - Steady States: If you’re testing long running process. You must take the ramp up time and performance hit into your initial measurements. - - Sampling Error: Data should perform have a steady variance or range. If you get wild swings or sudden spikes, etc. then you must either account for the reason why or you have a sampling error. + - Steady States: If you’re testing long running process, you must take the ramp up time and performance hit into your initial measurements. + - Sampling Error: Data performance should have a steady variance or range. If you get wild swings or sudden spikes, etc. then you must either account for the reason why or you have a sampling error. - Measurement Error: Aka Human error, always go through your calculations at least twice to make sure there are no mathematical errors. . * Do a small run of the experiment to verify the design. * Use the small run to determine a proper sample size. -- 1.5.6 From f67815f891b3667f52b9e697385b570a107bc38a Mon Sep 17 00:00:00 2001 From: Alan DaCosta Date: Thu, 6 Nov 2008 08:38:23 -0800 Subject: [PATCH] Fix guide typos --- .../guides/source/debugging_rails_applications.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/railties/doc/guides/source/debugging_rails_applications.txt b/railties/doc/guides/source/debugging_rails_applications.txt index b45473f..4425d92 100644 --- a/railties/doc/guides/source/debugging_rails_applications.txt +++ b/railties/doc/guides/source/debugging_rails_applications.txt @@ -595,7 +595,7 @@ To list all active catchpoints use `catch`. There are two ways to resume execution of an application that is stopped in the debugger: * `continue` [line-specification] (or `c`): resume program execution, at the address where your script last stopped; any breakpoints set at that address are bypassed. The optional argument line-specification allows you to specify a line number to set a one-time breakpoint which is deleted when that breakpoint is reached. -* `finish` [frame-number] (or `fin`): execute until the selected stack frame returns. If no frame number is given, the application run until the currently selected frame returns. The currently selected frame starts out the most-recent frame or 0 if no frame positioning (e.g up, down or frame) has been performed. If a frame number is given it will run until the specified frame returns. +* `finish` [frame-number] (or `fin`): execute until the selected stack frame returns. If no frame number is given, the application will run until the currently selected frame returns. The currently selected frame starts out the most-recent frame or 0 if no frame positioning (e.g up, down or frame) has been performed. If a frame number is given it will run until the specified frame returns. === Editing @@ -704,7 +704,7 @@ For further information on how to install Valgrind and use with Ruby, refer to l There are some Rails plugins to help you to find errors and debug your application. Here is a list of useful plugins for debugging: -* link:http://github.com/drnic/rails-footnotes/tree/master[Footnotes]: Every Rails page has footnotes that link give request information and link back to your source via TextMate. +* link:http://github.com/drnic/rails-footnotes/tree/master[Footnotes]: Every Rails page has footnotes that give request information and link back to your source via TextMate. * link:http://github.com/ntalbott/query_trace/tree/master[Query Trace]: Adds query origin tracing to your logs. * link:http://github.com/dan-manges/query_stats/tree/master[Query Stats]: A Rails plugin to track database queries. * link:http://code.google.com/p/query-reviewer/[Query Reviewer]: This rails plugin not only runs "EXPLAIN" before each of your select queries in development, but provides a small DIV in the rendered output of each page with the summary of warnings for each query that it analyzed. -- 1.5.6