We're not, but both accuracy and security have precedence over performance. We're doing a deep dive on the problem and our systems to see if someone could actually pull off a security breach even with all the other layers of security that we have. If it turns out that the answer is "Yes, someone could", then two things will happen...
1. We'll take the hit on performance as a first step.
2. Although this is one place where performance may not be entirely "in the code", we know exactly how long our current stuff takes to execute whether it's GUI code or large batch code and we'll be looking for slowdowns. Since almost all code has a "good enough" nature in it, there's always room for improvement and improve it we shall.
We're setting up to do tests on our staging boxes because we also know how long things take to run there, as well. We also have a PreProd box for our "money maker" where most of the action both on the front end and for batch code takes place. We'll be doing testing there, as well, to see if we can catch anything early.
Jeez... this reminds me of the recent thing with Volkswagon. What a pain in the ass all of this is going to be for a whole lot of people and companies.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair
How to post code problemsHow to post performance problemsForum FAQs