I use PHPStorm 5.0.2 for debugging php/mysql projects with WAMP framework (php 5.3.1, Apache 2.2.9, mysql 5.5.24 on Windows 7 platform).
Question 1: Some times in a project, when watch debug variables are used, they take some seconds to refresh on the debug panel, after each code step. Each watch variable takes a few seconds to refresh, so the more watches have been defined, the more slowing down takes place during code stepping, rendering debugging disappointedly slow. So, for example, I cannot press 'Step over' every second, because I have to wait till watch values are refreshed, before I press the next 'Step over' and this may take 5 or more seconds.
This didn't use to happen before, it started happening lately and also it doesn't happen all the time. When it doesn't happen, the code stepping can advance very quickly, as it usually did.
In this project I have set up quite a few breakpoints, so I was wondering if they are the culprit. I tried to disable most of them (not delete them, since I need to keep them for future use), but I didn't see any improvement.
I also tried different xdebug versions, but no change took place.
I have also tried to switch browsers, delete browser data (cache, etc), restart WAMP server, browser, phpStorm, even Windows, but many times the issue remains. Other times, it disappears for a little while and it reappears later in the code.
I was wondering what reasons might produce this slow refresh.
Question 2: Is there any way to export or save breakpoints from a project?
Question 3: If I tried PHPStorm 7, in case this slow-refresh issue disappeared, could I open the PHPStorm 5 project in order to not loose the breakpoints I have already set?
Related
I just made a strange observation in my windows 10 based symfony installation.
I always got rather dissapointing response times, so I wanted to use the profiler to check for reasons.
I found one interesting deviation immediately: Although the profiler sums the totals to about 1000 ms, the browser shows that the TTFB is about 5800ms?
My public\index.php is the same as
https://github.com/symfony/recipes/blob/master/symfony/framework-bundle/4.4/public/index.php
And here is the thing: When I put an exit() right after $kernel->terminate($request, $response); my browsers TTFB is suddenly at 1600ms!!!
This is mind blowing, cause I always thought nothing happens after the last line in index.php?
Can someone explain, why my symfony route calls are blocked for SECONDS after they are ready?
Turns out that this delay must have to do something with xdebug enabled in my php.ini, while the IDE (VS CODE in my example) was not running the debugger.
When I turn on debugging in the IDE (and I remove all breakpoints) the TTFB is as short as with the exit() in place.
When I switch off Xdebug, it is the same.
I think xdebug trying to communicate with the IDE (and not succeeding) must block the HTTP Response for the additional 2 - 3 seconds.
Fresh installation - plugins disabled, no malware. Chromium runs without delays. Firefox on every other action, including typing every now and then - takes 3-5 second pauses, sometimes displays a running wheel when the delay is even longer.
Started at certain point in time. De-installation/re-installation didn't cure. Running as a single process didn't cure. Latest version.
Any ideas what can be causing this, specifically for the Firefox?
Upgrade to v67 - I remember reading some glitch has been removed in prior versions that might have been causing this behavior.
Also, another idea would be not to limit your cache to a very low space.
+1 to move this question to SuperUser.
I'm developing a web app running on WildFly 8.2 and I'm experiencing annoying UI responsiveness lags that I do know how to pinpoint. The lags occur shortly after loading a new page - they last about 3-4 seconds during which all UI is not responsive (such as hovering does not have effect, you cannot close the window or open DevTools)
I considered the following aspects:
code-related - angular, animations, kendo, less.js, not optimized selectors or iterators in my code, etc. Disproved - I rolled back to a very early version where I had never observed the problem (so to eliminate a hidden impact of newly introduced features), and the problem was there too.
CPU-related - restarted afresh many a time, running no extra apps - no go.
server-related
browser-related - disabled extensions and hardware acceleration setting - disproved. Chrome/FF usually silently choke, sometimes asking whether to close unresponsive page, IE complains about script, but when I choose to Debug the script, all I get is being directed to random script.
The key test however was to view my local deployment over LAN from other desktops - the app performed sluggishly regardless, whereas the same app (same code, same branch revision) deployed locally on those desktops performed superbly.
So this proved this is more server- or CPU related stuff. The app ran fine on WildFly 8.0. When the problem started to bite, I upgraded to 8.2 but it does not seem to have any effect.
As I'm running out of ideas, does anyone seem to have a hint what to do/check next?
Last minute: I went along the advice from here http://www.tomshardware.co.uk/forum/1843-73-windows-slow-browsing-chrome-firefox-faster and turned off Windows Defender's real-time protection - nothing got better.
The problem was caused by invisible content (shown on request in a modal) that grew up to 5000+ table rows and was employing angular binding (ng-repeat a.o.). Thanks for your hints.
I'm using Visual Studio 2012 Update 3. When I open a project, VS automatically creates a process called <myproject>.vshost.exe, even before starting to debug.
When I start debugging and later close the debug application, most of the times the <myproject>.vshost.exe process closes as well. When this happens, devenv.exe starts taking up 3x more memory than normal and CPU goes up to 25% (on a i7 Quadcore with 8GB ram) for around 1 minute. At the end of 1 minute, a new <myproject>.vshost.exe opens up (even though I'm not debugging), CPU falls back down to 0 and memory drops back down as well.
Trying to start debugging whilst the CPU is at 25% and <myproject>.vshost.exe is not running in the background will results in the solution building but the debug does not start.
If I wait until the CPU falls back down and <myproject>.vshost.exe process is running again then I can start debugging normally.
This happens to me 80% of the times after closing the application I am debugging. The remaining 20% of the times when I stop debugging <myproject>.vshost.exe continues running in the background and I am able to start debugging again immediately after with no delay.
This also happens regardless of code changes in between debugs.
This is a new install of VS2012 U3, I've tried resetting all settings and disabled ReSharper but still no joy.
I don't want to disable vshost debugging because of the features I would lose.
Has anyone else encountered this problem before? Is this a known issue? Are there any solutions/workarounds?
EDIT
I changed the platform from Any CPU to x86 and it appears to work properly, but I still can't understand why I shouldn't be able to debug it as Any CPU. Even though this might be the workaround I'd still be interested in knowing whether this is a known issue and if there are other (better) solutions.
By 'working properly', I mean that when I stop debugging the vshost doesn't close, in fact it never closes, but the CPU of devenv stays at 0% and it allows me to start and stop debugging as many times as I want one right after the other.
EDIT2
Actually it appears that changing the platform to x86 only worked properly for a while, after about 20 rebuilds it is now doing the same as leaving it as Any CPU.
On another note, closing and opening VS makes no difference.
I've ended up formatting the computer again and re-installing everything from scratch. For not it appears to be working fine, let's see how long this lasts for.
I know this is several months old but I'm trying to post this answer in a few places since this is what was causing my ills: I had the Data Sources toolbox open in Visual Studio 2012. Once I closed that, it seemed to eliminate the lengthy delays when switching windows. You may also want to close Server Manager if you don't need it open.
I know this is old Post but, I think I need to share my solution for everyone.
and this is my first post so, please improve the answer if I miss something.
I have the same issue with Visual Studio 2012, When I try to build or debug it will use CPU up to 100%.
So, I try below steps to reduce the CPU usage while debugging:
Please close unnecessary opened file.
Hide unnecessary debugging panels like: breakpoints, auto, local, output, find symbol result, etc.
If still use high CPU then try to hide call stack panel.
Remove unnecessary breakpoints.
I'm currently learning OpenGL and I've noticed a rarely occuring performance problem:
My program is rather small so it's not a performance problem with the code itself, but when I'm running the code via Visual Studio I sometimes only get 1-2 FPS instead of the usual 60.
Once this happens I can restart the program as often as I want to (in debug and release mode alike) and it won't go away.
However, when I close my Firefox (or manually shut down the plugin-container.exe though task manager) and restart my program everything is fine again. After that I can start Firefox again (with the same tabs open) and the bug does not reappear.
I use the newest version of Firefox, and I've had this bug with several programs already - both made by me and others and using different versions of OpenGL. However I don't think I've had this problem when starting a compiled exe directly, but only by using the Run feature of Visual Studio.
I've searched the web but I only found a link about the generally bad performance of this plugin-container.
Does anyone else have this problem? Do you know any walkarounds or fixes?
PS: Regarding isti_spl's answer:
The CPU utilisation of the plugin-container.exe jumps to the 50% limit when the problem happens.
I'm working with Visual Studio, but the problem only occurs when I also have Firefox running (it most certainly is because of this plugin-container, so it probably won't happen with other browsers).
It's hard to isolate the problem because I can't replicate it. It might happen 1 out of 50 times.
I'll see if closing flash-related tabs (youtube, blip.tv etc) fixes the problem next time it happens.
Can you isolate the problem?
You first mentioned running visual studio then firefox. Please try to run separately.
Under FF. is it caused by WebGL or flash plugin? Is it caused by visiting specific sites?
Is it FF specific or happens under other browsers too?
Does CPU utilisation jump high? Please verify that too and which process consumes most CPU.
Not sure, but likely gpu driver + flash problems.
If so, the problem is not in your code, other GL program should be affected too.