Almost everyone I know complains about the performance of their computer when an anti-virus (A/V) product has installed, and thinks they need more memory or a faster processor. Wrong! You need to get a faster hard disk, or disable scanning of certain files.
You'll see from Task Manager that memory and other resources are plentiful on a modern computer, but page faults and other disk I/O (hidden by default) are occurring at very high levels. Disk I/O is still slow on modern computers and you'll get better performance gains from improving this aspect.
Most A/V software has settings that let you control:
Scanning inside archives like .zip files. Only files downloaded from the Internet or via other media are major threats. Consider tweaking these settings to avoid scanning too deeply into archives, or only scan in risky locations (external drives or downloads folder).
Directories that excluded from automatic scanning. Real-time protection is valuable for certain users, but there may be files that a user must access very frequently. These include databases or virtual machines. Consider disabling real-time scanning of these files/folders.
Making changes to these settings will benefit performance, and security can still be maintained to a very high level. You are running Windows under a normal user account, aren't you?
It's common to see .NET developers and SQL Server DBAs arguing over the merits of stored procedures versus inline (ad hoc) SQL. It's unfortunate that these folks are so polarised since there is a solution that meets somewhere in the middle. It's called parameterised SQL and it's similar to inline SQL, except that it's based on templates. You effectively have the SQL that exists in a stored procedure, and you specify input/output parameters in the same way as you do for stored procedures. This SQL is then placed in the data access layer of your application.
From what I understand, Microsoft are using this for DLinq and have dropped their recommendation on the use of stored procedure. I'm all in favour of this method since it makes upgrading applications so much simpler, and reduces your dependency on the DBA whilst maintaining a level of protection from SQL injection attacks. There is the point about setting security on individual stored procedures - but how many people really do that? Even when they do they often leave themselves open to other attack vectors.
Expat Coder