Sign in
Rico Mariani's Performance Tidbits
Implying no warranties and conferring no rights: "AS IS" since 1988
Translate This Page
Translate this page
Powered by
Microsoft® Translator
Options
Blog Home
Email Blog Author
Share this
RSS for posts
Atom
RSS for comments
Search
Tags
databases
debuggers
design advice
History of Visual Studio
locking
Pages
performance
quiz
ramblings
recommendations
signatures
using tools
visual studio
Archive
Archives
March 2012
(3)
February 2012
(3)
January 2012
(3)
December 2011
(1)
November 2011
(1)
September 2011
(1)
September 2010
(1)
June 2010
(1)
April 2010
(5)
December 2009
(1)
October 2009
(13)
September 2009
(2)
August 2009
(1)
June 2009
(3)
May 2009
(3)
December 2008
(1)
November 2008
(4)
September 2008
(2)
August 2008
(6)
June 2008
(2)
May 2008
(2)
February 2008
(2)
January 2008
(2)
November 2007
(5)
October 2007
(2)
September 2007
(3)
August 2007
(3)
July 2007
(3)
June 2007
(6)
May 2007
(1)
April 2007
(2)
March 2007
(1)
February 2007
(5)
January 2007
(7)
December 2006
(2)
November 2006
(1)
September 2006
(4)
August 2006
(4)
July 2006
(12)
June 2006
(3)
May 2006
(5)
April 2006
(6)
March 2006
(6)
February 2006
(2)
January 2006
(2)
December 2005
(2)
November 2005
(8)
October 2005
(4)
September 2005
(4)
August 2005
(7)
July 2005
(2)
June 2005
(3)
May 2005
(12)
April 2005
(3)
March 2005
(5)
February 2005
(2)
January 2005
(3)
December 2004
(2)
November 2004
(2)
October 2004
(3)
September 2004
(4)
August 2004
(3)
July 2004
(4)
June 2004
(8)
May 2004
(6)
April 2004
(4)
March 2004
(8)
February 2004
(4)
January 2004
(3)
December 2003
(11)
He will triumph who knows when to wrap and when not to
MSDN Blogs
>
Rico Mariani's Performance Tidbits
>
He will triumph who knows when to wrap and when not to
He will triumph who knows when to wrap and when not to
ricom
5 Mar 2004 12:50 PM
Comments
2
This advice is somewhat redundant with what I posted a few days ago but, what the heck, it's got more spicy goodness than the previous formulation.
Where your underlying functionality is extraordinarily fast
you cannot afford to add levels of abstraction whose processing cost will dwarf the actual work that needs to be done.
This would be a case of construction with all glue and no wood
.
For example, if we're talking about a function that will do a few clocks worth of math, it's a bad idea to spend a few dozen clocks on assorted virtual dispatches and stack repackaging. Even though you might get some elegant factoring of the code, it might be a bad idea to do that factoring. The more meaty the work gets, the more compelling the factoring becomes.
Said another way, just because you can factor some code into nice interfaces
doesn't mean that it is a good idea to do so
.
Know your limits, abstract responsibly.
2 Comments
performance
,
design advice
Blog - Comment List MSDN TechNet
Comments
Loading...