What features to sacrifice for speed?

Just out of curiosity, have you tried invalidating file caches to make it re-create them?  I ask because I frequently work with really old PHP 3-4 code that is 6-10,000 lines of code per file and I've never seen PHPStorm chug even once trying to work through it.  Even on my old laptop with a 5400 RPM hard drive and 4 GB of RAM.  I think there's something wrong with your install if it's taking more than a couple of seconds to do just about any function (except maybe indexing an entire project on initial load).

It must be something wrong, hence the thread. The aim is to find a way to make an educated guess what's wrong.

http://devnet.jetbrains.com/docs/DOC-1253

http://devnet.jetbrains.com/message/5502251#5502251

Yep... somehow missed it completely, sorry.

In any case: when you submitting a ticket to the Issue Tracker you can make any attachment (as well as whole ticket, if desired so) visible to devs only -- depends on your "private information" (how important that info is) it may be enough.

P.S.
Have you tried "Power save mode" -- any noticeable difference?

Unfortunately "private sharing" is not an option. The restriction lays in the legal field and I'm afraid marking the ticket as "invisible for public" doesn't change the fact that JetBrains team is a 3rd party, and the snapshot contains information that is an object of NDA. I can change nothing at the moment, yet it may be an interesting topic to discuss in another thread.

Returning to the original question, the turning code analysis off by switching to powersafe mode works. I learned it from this forum next day after upgrade. The problem is that it is kind of a guillotine which cuts off one of the selling point of the IDE (http://www.jetbrains.com/phpstorm/), and I am asking about a scalpel to FINE TUNE the inspections, or any other settings for better performance.

To make it clear I love the idea of inspections, code highlighting, hinting and all other features that makes the difference. Using codesniffer in realtime is much more convenient, than in pre-commit hooks, for example.   As I was saying I am ready to invest into hardware to make all these features work, but it seems it is not enough any more.

There are over 300 inspections. Frankly, I am not not sure what most of them do, and how valuable  each individual one.  What I am asking, is an advice how to analyse performance impact of different options and turn off the most expensive ones.

My first intention was to create a drosophila project to replicate the problem in isolation and submit the CPU snapshot, but it doesn't work. Code of the same file is analysed in few seconds when it is the only file in a project. It is very acceptable result, and there is nothing to complain. It seems to be very project specific, rather than a bug to report. Hence the discussion. I just want to learn how to use the IDE effectively, if it is possible at all.

Ideally, I would like the IDE to report about all expensive operations as it does with phpcs. When it takes more than few seconds, it stops the script with error notification in the event log. From one hand it  instantly unblocks me, and from another hand it  indicates what feature to turn off if it happens often.  

I don't mean to sound like a broken record, but aren't you going about the problem the wrong way?  You're trying to treat the symptoms instead of treating the problem.  I work on projects ranging in size from tens of thousands of files, some large some small, to mom and pop shops with 10 pages on the entire site.  I've never had slowness issues, and I'm hardly running what I would call a monster machine.

The issue you're having is that you're experiencing performance issues that are impacting your work.  You're trying to fix the problem by turning stuff off to mask the fact that the problem exists in the first place.  The bigger problem is something is either very wrong in your setup or very broken in your installation.  I'm frankly not sure what the problem could be with setup unless you're trying to load your project off of a network with bad latency issues.

Either way, I'm not trying to be difficult, I just think it'd be wrong to go through the motions of crippling the IDEs main selling features to fix a problem that isn't being caused by the IDE itself, but rather by the environment.  As for how to diagnose and fix these problems... that's where I'm not sure how to help you.  All I can say is I've run PhpStorm from full desktops to terrible laptops and I've never had a performance problem on any of my projects, so you should try looking at what makes your environment unique... if at all possible.

I sincerely hope you find the problem and get it resolved :)

Thanks Deric. To be honest, the project is quite unique in many ways, and I have little to no control over most of it's parts.
If there is no way to tune the v7, I will switch back to v6 till end of the contract. Not a big deal really.

Since this is rather a project specific issue ... then IF you have time and desire you may try the following:

• backup and delete .idea subfolder (the project settings) ... or just copy project files into another folder
• open that folder as brand new project -- see how it will behave
• if all good -- start configuring it (like adding additional libraries and similar)
  
• do it in rather small incremental steps (maybe close/reopen project (or whole IDE) after each step) -- you should be able to notice at what point it starts lagging -- it may point you to some clues or what may be wrong.

Thanks Andriy. Unfortunately it did not work. In fact it made it even worse. With newly cloned project it took 16 minutes to "close the eye" (screenshot1) with default inspections. When I unchecked all the inspections (screenshot2) and reopen the IDE, it took only 7 minutes, and I still have some of them reporting problems. When I open "Edit inspection" from the context menu for the one one screenshot 3, I've got screenshot 4.

I really love the UI pattern to disable inspections on the go from editor window. In most project It is enough to accept defaults, and fine tune some, when needed.
Unfortunately there is no profiler to do the same from performance point of view.
I don't mind to use external ones, like http://yourkit.com, and what I need is little help to read the snapshots. The names are pretty much self-explanatory, but I still have no clue what to do.

I cannot help you with profiling, unfortunately. Not a Java guy, at all :( .

If you wish (and have time to do so) -- I may only suggest exclude/delete one of the project sub-folders and "File | Invalidate caches" -- if you see dramatic changes then most likely problematic file(s) was one of them (or maybe other way around: leave only small part of the project and add folder by folder).

I remember seeing some tickets (in the past) where one big complex file was causing IDE to index it for a long time (or even run indexing indefinitely). Such file could be a PHP or some big SQL dump, or lots of high resolution images etc. Just for example: WI-20377, IDEA-97613. Maybe you have something like that in your project?

Also -- have you tried fresh/clean install? By "fresh install" I mean backing up and deleting IDE-wide settings (e.g. C:\Users\USERNAME\.WebIde70 on Windows 7 for PhpStorm v7). On some (only some) occasions it helped.

Another idea is to try this project on another (preferably similar) computer -- if it is possible, of course. Maybe it's a hardware/other software that slows down the whole system somehow? But since you do not have issue with one file in the project then I think you may have similar result even there.

Thanks Andriy,

Although the problem is not solved, I really appreciate your and Deric's input.

I give up and switch back to v6, which is acceptable slow.

What is learned from my tambourine dances around that black box, aka facts & assumptions :

• system: Ubuntu 13.04, Sun Java 1.7
• the project is relatively big: 1.2 mln+ lines in own php files, excluding compiles; 2.5 mln+ lines in all php files including vendors; 1.1 Gb+ total on disk including assets, excluding vcs files; 2k+ tables;  the IDE use 1.7 GB RAM  (1.2 GB for v6)
  
• it ran 6 times longer to analyse the same file in newly cloned project because I did not exclude any directories, which is my fault
• the same file is analysed in a second or two, when it is the only file in a project
  
• the file itself is 600 lines, yet contains php required_once, javascript includes, and classes autoloaded by composer
  
• turning off all inspections helps a little
  
• switch to Power Save mode does the job, as well as turning code analysis for individual file from Code => Configure Current File Analysis menu
  
• as shown on the attached image, it slows down on syntax analysis before inspections, which explains why unchecking all inspections helps only partially
  
• there are not too much options to tune code analysis: it is on, off for a file, or off for all files
  
• if I understand it loads all (required?) files to analyse syntax of the opened one, which makes it tricky to reproduce the problem in isolation or even make a formal bug report
  
• it seems quality of code matters: a half-size project (sonata bundles + some zend2) works pretty quick while half of the original project still require more than a minute to process a file
  
• there are no major network or disk activity, but CPU only.

Looks like it is not a bug, but a feature. Whilst versions < 7 encourage devs to write good code by adding convenient features, v7 does it in a bit more aggressive way by blocking programmers to work with poor quality code =) Or in other words, the new code analyser is designed for projects with good, semantically correct code, rather than legacy php. V7 is just a wrong tool for the specific project, which is fair enough.

Well. This one looks interesting.

Our ultimate target is to work snappy with any code out of the box.
We do our best to eliminating performance edge cases, making each new version actually faster despite added features.

So I really really like to see a performance snapshot for that 600 line file - lets say 5 full passes each after keypress.
Can you please file a performance problem to http://youtrack.jetbrains.net/issues/WI#newissue=yes putting last post contents and a snapshot - made in yesterday's 7.0.1 EAP?..

Thanks Alexey. That's a perfect target to aim to, and I believe you do the best you can. I deeply apologize if my previous comment was too sarcastic. The IDE is the best one and I enjoy working with it for last several years.

I would love to help you by submitting a snapshot if I could. Unfortunately I can't, and I already explained my reasons.
The only things I could do were to analyse the snapshot myself, or replicate the problem in isolation. I did both with no luck, you know. If there's anything else I can do for you, I will do with pleasure.

As I was saying, I have no problems to work with v6. I did it from the first days on the project, and that's ok to do it for few more months.

Well we dont want *memory* snapshots or even IDE logs.
We need only *CPU* snapshots - made by built-in YourKit agent actually.
Those are basically aggregated threaddumps of IDE itself plus some JVM heap *stats* and do not contain any sensitive information -
well exept some local system paths visible on the summary & probe pages - you can easilly verify how "clean" it actually is opening one in YourKit.

Unfortuntately we can't proceed without getting those profiles - often with multiple iterations.

And analysing those by yourself is totally unrealistic, sorry.

Yes, unfortunately that's true. Thanks anyway.