Removing ?debug_profile=1
Sam Minnee
I've been tidying up some if the bootstrap code in main.php, and I
want to propose that we remove the ?debug_profile=1 feature.
In particular, I would advocate that anyone wanting to profile their
SilverStripe site uses Webgrind, which is a **much** better profiler.
It does mean that you have to install xdebug on your development box,
but this seems like a reasonable expectation.
What do people think? Is there a good reason to keep ?debug_profile=1
active in the system?
stojg
viable option than using the ?debug_profile=1.
+1 internet for removing it!
Tim Klein
i'd keep it
-1
--
You received this message because you are subscribed to the Google Groups "SilverStripe Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
--
Tim Klein
address: Level 1, 1 Searle Lane, Queenstown
skype: kelptim
email: t...@kelpdesign.com
website: http://www.kelpdesign.com
phone: +64 3 409 2031
mobile: +64 21 234 35 78
dalesaurus
without fussing with extra tools. However webgrind is more suited to
tuning, maybe remove or replace debug_profile with a more high level
view? I use it when I want to know if my DB is lagging, which
templates are killing load times, or if I need to look at disk IO as
many hosts can drag there.
+1 with a replacement strategy
-1 without one
On Jan 28, 5:30 am, Tim Klein <t...@kelpdesign.com> wrote:
> quick and simple way of checking why things are slow. especially when you
> cant set up xdebug on your host...
>
> i'd keep it
>
> -1
>
>
>
> On Thu, Jan 28, 2010 at 9:31 PM, stojg <stojg.lindqv...@gmail.com> wrote:
> > No, I think as you said that using xdebug profiling tools are a more
> > viable option than using the ?debug_profile=1.
>
> > +1 internet for removing it!
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "SilverStripe Development" group.
> > To post to this group, send email to silverst...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > silverstripe-d...@googlegroups.com<silverstripe-dev%2Bunsu...@googlegroups.com>
Mateusz Uzdowski
slow. It does not give perfect results, but can quickly highlight
where is the bottleneck. I'd say it's 'good enough'. I vote for
keeping that, maybe just put a note somewhere explaining what's the
mysterious 'all execution' and that people shouldn't base any medical
procedures on the results, as they are not reliable enough :)
> To post to this group, send email to silverstripe-
> d...@googlegroups.com.
> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com
Hamish Campbell
I've used debug_profile to optimize big queries and find bottlenecks
in live systems a few times and it was a life-saver. From a core POV I
can see webgrind being essential, but for developers debugging/
optimization debug_profile works just fine.
Regards
Hamish
> >>> silverstripe-d...@googlegroups.com<silverstripe-dev%2Bunsubscrib e...@googlegroups.com
Bjorn Radon
I found a horrible exploit which was fixed in the 2.3.5 release, based on a query parameter, so I am in favour of removing as many as possible.
Maybe an observable/observer pattern can be applied in the core classes? With some standard observers (with text or html file output) that can be enabled by the site config or similar the need for easy debugging could be met. Maybe this is coming up with the logging functionality in trunk
Björn Radon
--
You received this message because you are subscribed to the Google Groups "SilverStripe Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
Hamish Campbell
either had to be in dev mode or authenticated as admin.
On Jan 30, 3:13 am, Bjorn Radon <bjorn.ra...@gmail.com> wrote:
> Hi, I'm definitely for removing ?debug_profile, in fact I'm in favour in
> removing most $_GET - solutions that end up cluttering the source code.
> debug_memory could go as well imho. As far as I can see it is accessible on
> all SilverStripe sites, if it is not explicitly checked for in the .htaccess
> file. I don't like features that helps people determine what platform I am
> running my sites on, it opens them up for targeted attacks...
> I found a horrible exploit which was fixed in the 2.3.5 release, based on a
> query parameter, so I am in favour of removing as many as possible.
>
> Maybe an observable/observer pattern can be applied in the core classes?
> With some standard observers (with text or html file output) that can be
> enabled by the site config or similar the need for easy debugging could be
> met. Maybe this is coming up with the logging functionality in trunk
>
> Björn Radon
>
> 2010/1/28 Sam Minnee <sam.min...@gmail.com>
>
>
>
> > Hi everyone,
>
> > I've been tidying up some if the bootstrap code in main.php, and I
> > want to propose that we remove the ?debug_profile=1 feature.
>
> > In particular, I would advocate that anyone wanting to profile their
> > SilverStripe site uses Webgrind, which is a **much** better profiler.
> > It does mean that you have to install xdebug on your development box,
> > but this seems like a reasonable expectation.
>
> > What do people think? Is there a good reason to keep ?debug_profile=1
> > active in the system?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "SilverStripe Development" group.
> > To post to this group, send email to silverst...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > silverstripe-d...@googlegroups.com<silverstripe-dev%2Bunsubscrib e...@googlegroups.com>
Andrew de Lisle
Any debugging or testing should be enabled on a local environment not
by $_GET variables.
+1 for getting rid of debug_profile and debug_memory
- Andrew
On Jan 29, 3:13 pm, Bjorn Radon <bjorn.ra...@gmail.com> wrote:
> Hi, I'm definitely for removing ?debug_profile, in fact I'm in favour in
> removing most $_GET - solutions that end up cluttering the source code.
> debug_memory could go as well imho. As far as I can see it is accessible on
> all SilverStripe sites, if it is not explicitly checked for in the .htaccess
> file. I don't like features that helps people determine what platform I am
> running my sites on, it opens them up for targeted attacks...
> I found a horrible exploit which was fixed in the 2.3.5 release, based on a
> query parameter, so I am in favour of removing as many as possible.
>
> Maybe an observable/observer pattern can be applied in the core classes?
> With some standard observers (with text or html file output) that can be
> enabled by the site config or similar the need for easy debugging could be
> met. Maybe this is coming up with the logging functionality in trunk
>
> Björn Radon
>
> 2010/1/28 Sam Minnee <sam.min...@gmail.com>
>
> > Hi everyone,
>
> > I've been tidying up some if the bootstrap code in main.php, and I
> > want to propose that we remove the ?debug_profile=1 feature.
>
> > In particular, I would advocate that anyone wanting to profile their
> > SilverStripe site uses Webgrind, which is a **much** better profiler.
> > It does mean that you have to install xdebug on your development box,
> > but this seems like a reasonable expectation.
>
> > What do people think? Is there a good reason to keep ?debug_profile=1
> > active in the system?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "SilverStripe Development" group.
> > To post to this group, send email to silverst...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > silverstripe-d...@googlegroups.com<silverstripe-dev%2Bunsu...@googlegroups.com>
Hamish Campbell
debug_memory (10 months ago) and debug_profile (7 months ago). Both
are in the 2.4 branch, but never made it to 2.3.x
http://open.silverstripe.org/changeset/80057
http://open.silverstripe.org/changeset/74067
So, just got to wait a little longer.
> > > silverstripe-d...@googlegroups.com<silverstripe-dev%2Bunsubscrib e...@googlegroups.com>
Ingo Schommer
I've merged back to 2.3 in r98229 and r98230.
We're prepping a new 2.3 security release anyway,
so this will be included there as well.
> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
>
>
-------
Ingo Schommer | Senior Developer
SilverStripe
http://silverstripe.com
Phone: +64 4 978 7330 ext 42
Skype: chillu23
Sam Minnee
> Any debugging or testing should be enabled on a local environment not
> by $_GET variables.
>
> +1 for getting rid of debug_profile and debug_memory
How about we only allow the use of debug_profile if an
SS_ALLOW_DEBUG_PROFILE define is set, and $_GET['debug_profile'] is
set?