1. Mixed mode with current code is really hard to implement, so I defer this to
separate repository.
2. Yes. With pure profile mode we haven’t any connection to debugger. The only
way is manual importing cache grind file (already done). To simplify this I
would like to introduce dir scanner (especially for SSH connections), where
user can easy import via double click. Se also how work webgrind.
3.In this way we working right now. xdebug can populate aggregated files, but
I didn’t test this yet.
4. We haven’t response header, especially in pure profile. We only have list of
cache grind files and can read it’s creation date. If user select correct name
schema, we can detect url, date etc..[1]
5. It’s related to point 2. We should watch output dir via SSH session, and
download file on demand.
Current patch state:
1. Support cache grind manual import with state saving
2. Support php executable profiling session. PHPUnit support should be done via
separate thread, mostly due nightmare in launchdelegates
What we read from file:
1. Complete call tree with timestamps
2. List of files / classes / functions and it’s positions
UI allow:
1. Navigate over call tree
2. Navigate to call file:position
3. Navigate to definition file:position
4. Display invocation statics (call and callers list)
I would like to drop “[WIP]” and merge patch as is and continue work via
separate bugs like:
1. Support xdebug 2.6 memory statistics
2. Reduce UI freezing as much as possible - Execution Statistics tree it’s
extremely slow
3. Improvements around Invocation Statistic tables. I thinking about docking
inside Execution Statistics, and show call/callers based on current selection.
4. Model improvements to allow flag call tree positions as “internal function
call”, “file includes include” etc.. and filters for that
5. output_dir scanner
6. Support xdebug trace file
7. General performance improvements, currently pdt store everything in memory.
Disk store is must have
8. Dark theme improvements
9. probably more … this patch opens another window in my head :P
[1] - https://xdebug.org/docs/all_settings#trace_output_name
From: Michele Locati <[email protected]>
Reply: PDT Developers <[email protected]>
Date: 2 May 2018 at 18:01:59
To: PDT Developers <[email protected]>
Subject: Re: [pdt-dev] xDebug profiller
Hi David,
1. Yes, I'd prefer a checkbox in "profile" launch instead of adding a new
"profile and debug" profile
2. Would that work also when the server is not directly controlled by PDT (like
Apache or NGINX)?
3. I'd prefer a profile session for each request: profiling is very helpful to
see where a request is taking a lot of time, and mixing requests in the same
session would make it harder.
4. What about adding a filter for the Content-Type response header? We could
also add a filter for paths (eg "I want to profile the requests that starts
with "/path/to/uri/resource/")
5. I don't understand ;)
--
Michele
2018-04-28 19:11 GMT+02:00 Dawid Pakuła <[email protected]>:
Hi Team,
I’m playing with xDebug profiler and thinking about possible integration.
Currently I have couple concerns:
1. We need support PROFILE and PROFILE+DEBUG mode. I think debug as optional
checkbox in profile launch configuration. What you think?
2. For web launch we need place where to store “xdebug.profiler_output_dir”.
For EXE we can easy read (or override) this property before launch. What you
think about settings in server configuration + ability to override on web
launch level?
3. I’m not sure how to play with multiple request. Auto aggregate or prepare
profile session for each request?
4. Despite of aggregation we definetely need way to filter requests. Any idea
how to prepare usable UI for that?
5. I’m not sure how efficiently watch SSH dir changes for new profile files.
Any ideas?
Besides I want extend “import profile session” wizard to support xdebug
cache-grind files (“simple" transform). This I hope will be good start before
implement watch deamons.
_______________________________________________
pdt-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/pdt-dev
_______________________________________________
pdt-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/pdt-dev
_______________________________________________
pdt-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/pdt-dev
