Whatever your .emacs and its improvements, you also should consider running emacs as a server at your session's opening :
Now, running emacs with
emacsclient -nw -c
or ... (see options) will be much faster
I've created this workaround, which pregenerates an agenda buffer whenever Emacs is idle for more than 5 seconds. The next time the agenda command is run, generation takes less than a second, since the org buffers have already been loaded.
(run-with-idle-timer 5 nil (lambda () (org-agenda-list) (delete-window)))
I'm not sure if you can do that using profiler.el as it is a sampling profiler. It's not actually measuring how long a function takes to run, it's periodically checking to see what function is currently being executed, and adding up all of those samples.
ELP or the EmacsLispProfiler is an instrumenting compiler. To enable instrumentation use M-x elp-...
Not quite an answer to your question, but consider (setq org-agenda-sticky t). This makes the q command bury the agenda buffer when you've finished with it, rather than close it.
The result of this is that the agenda will reappear immediately when you next ask for it, but it won't have been updated since you last saw it. If you want it updated you can ...
1) I have found esup to be a very convenient for Emacs startup profiling.
You just run M-x esup and get back list of all expressions in your init.el sorted by the time they took to execute. You don't need to restart Emacs or add anything special to the config, so narrowing on the slow down suspect becomes much easier.
2) I (use-package :defer t) all the ...
You can use
determine how long a command takes.
(benchmark 100 (command))
100 is the number of repetitions, make it large enough for you results
to be meaningful. And don’t forget you can also call it interactively.
(benchmark REPETITIONS FORM)
Print the time taken for REPETITIONS executions of FORM.
Interactively, REPETITIONS is ...
In profiler.el are two variables defined:
(24 right ((19 right)
(19 right ((14 right profiler-format-number)
Those seem to define the formatting of the report table.
You might want to ...
Side note, it is generally considered a good idea to have your startup code in ~/.emacs.d/init.el rather than ~/.emacs, one less hiden file in your home directory, a suffix so that other editors can guess the contents....
For bisection, the idea is that you stop running your .emacs about half way and see if it still takes a lot of time. If it does then you ...
You can use the package font-lock-profiler. For each font-lock rule, it measures execution time and the number of times the rule matched.
The package supports measuring time for highlighting a buffer or a region. It also allows measuring time during an editing session. Simply run font-lock-profiler-start, edit your text, and run font-lock-profiles-stop-and-...
setf the caar of profiler-report-cpu-line-format and profiler-report-memory-line-format to a larger width (default 50 and 55). It'll take effect on subsequent runs of profiler-report. (Thanks lawlist's comment for pointing out these variables.)
(setf (caar profiler-report-cpu-line-format) 80
(caar profiler-report-memory-line-format) 80)
Something you might try is increasing gc-cons-threshold - with packages like helm, they need more memory or might get slowed down - note that the garbage collector and helm take up most of your CPU time.
But if you set it too high, Emacs would freeze for some seconds when it finally garbage collects.
The default is 800kb - Spacemacs uses 100mb, so that's ...
With help from nanny and jordan biondo, I profiled, entered some newlines in a class, and found the following:
I don't tend to use imenu anyway, so I customised csharp-want-imenu to nil, rebooted, and now things are much much better.
Good work everyone!