Yes, bypassing the startup file makes Emacs start faster, but at the cost of my customizations not being effective. At that point, I may as well use vim or nano.

I never got around to setting up emacsclient and now routinely use multiple Emacs sessions, so I have doubts about its practicality for me. As to the resource usage of this solution, well... according to top, at the moment, all of my Emacs instances combined have about the same RAM footprint as the browser session dedicated to PerlMonks — the other browser sessions are much larger.

You are also correct that my projects are smaller, and I work very carefully to build up modules before using them. It is very rare for me to get an error in some module other than the one I am currently working on (and therefore already have in an Emacs frame) because I test each part very thoroughly. Devel::Cover is useful here. I probably would find a way to use Emacs M-x compile if I had projects spanning as many files as yours, with errors as scattered as you seem to encounter, although, for now, M-x speedbar meets my needs for quick file navigation.

emacsclient needs no setting up. Just add

(server-start)
[download]

to your startup file and open a file using emacsclient instead of emacs (I defined a shell function ec for that, and evan made it start emacs if it's not already running).

The only difference now is you close the files with C-x # instead of C-x k, but I wrote the following lisp function

(defun server-edit-or-close (buf)
  "Close the buffer regardless of whether it's a server file or not."
  (interactive "bKill/finish buffer: ")
  (if server-buffer-clients
      (progn
        (switch-to-buffer buf)
        (server-edit))
    (kill-buffer)))
[download]

and bound it to

(global-set-key  "\C-xk"  'server-edit-or-close)
[download]

and I can close a file using the standard way no matter how it was opened.

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]