OBJECT-ORIENTED OPTIMISATION
• Recap of Object-Oriented Programming
• The Purpose of Object Oriented Programming
Copyright By PowCoder代写 加微信 powcoder
• How Object-Oriented programming affects performance
Object-Oriented Programming Recap
• Object-Orientation is a programming style
• OO languages exist to make things easier
• OO style programs can be written in non OO languages
• OO style is not always followed when OO languages are used
• Key concept of the OO style is the Abstract Data Type (ADT)
• Programmer defines data structures (objects) and the operations (methods) that can be applied to these data structures
• External code only knows about the external interface
• Internal details are hidden (encapsulated) and can be modified provided the interface is preserved (It can be extended however)
The Purpose of OO Techniques
• OO is intended to manage the complexity of software development
• Code are easier to develop and maintain, number of bugs is reduced • Any impact on performance is coincidental to this primary aim
• Performance is however essential for HPC applications • OO techniques introduce specific performance issues
• Java has specific performance issues • In this lecture we consider:
• OO performance issues
• Java specific performance issues
Impact on performance
• In general OO techniques have a reputation for damaging code performance.
• Tend to be better than the worst unstructured code • But difficult to get full optimisation.
• However you can use OO encapsulation to aid in performance optimisation.
• In many codes 90% of the run-time is in 10% of the code.
• If you use OO to encapsulate this hot-spot (and its data structures) then its much easier to optimise without damaging the rest of the code.
How objects are implemented
• Each Object (An instance of a ADT) is implemented as a region of
memory containing the attribute data • Usuallyacontiguousregion
• Some attributes might be pointers to other objects • Access control is enforced at compile time
• Object methods are implemented the same way as any other function/subroutine
• The compiler adds a additional “hidden” argument to
method functions that passes the address of the object
being used to invoke the method
• This is often called the “this” pointer as it corresponds to the this keyword in C++/Java
Inheritance
• Most OO languages provide some form of “Inheritance”
where new classes are defined as extended versions of
existing classes
• Key point is that the extended objects can be used wherever a base object is valid
• Derived object looks like a base object with additional attributes appended
Virtual Function
• Virtual methods (methods that can be re-implemented)
need special handling. We want to call the derived
function even when accessed as a base type
• Methods accessed via a table of function pointers (vtable) • All objects in a class share the same vtable
• Inherited methods exist in multiple vtables
Vtable_ptr
Vtable_ptr
C++/Java • Java
• All classes are ultimately derived from Object
• All Objects have equivalent of a Vtable pointer
• Also classloader reference, lock variable …
• All methods are potentially virtual unless class/method
declared private or final. • C++
• Virtual methods need to be declared as such.
• A class with no virtual methods is a “concrete class” and its objects need not include a Vtable pointer
Multiple Inheritance
• Multiple Inheritance makes virtual methods more complex
• If you are extending more than one base class you cannot add attributes and methods to the end of the object/vtable
• Different base classes need different “this” pointer addresses. • To allow casting to different base classes
• Each base class needs its own vtable holding its part of the interface.
• Each method needs to be passed the “this” pointer corresponding to
the type that originally defined the method.
• Inherited methods only use the base class attributes. Overridden methods can recover the real this-pointer by applying an offset.
• Not an issue if your language does not use multiple inheritance (e.g. Java)
Interfaces
• Java interfaces are a simpler kind of multiple inheritance
• No problems with the this-pointer as code is not inherited
• Each method is implemented separately for each implementing class
• Different implementers may have methods at different vtable slots
• Could be implemented badly (search for method at each call)
• Or the JVM could have an “itable” for each interface class implements. May still be a problem if large number of interfaces are implemented
• Depends on the JVM implementation
Cache effects
• The OO programming style will have some impact on memory caching
• Data is grouped together in objects
• Data in the same cache line will tend to be from the same object
• Good if object attributes are closely related
• Bad if object contains data not used by the hot-spot. Some scope to address this by permuting order of object fields.
• Objects tend to take more memory • Usually rounded up to a convenient size
• Also needs space for the Vtable pointer
• Large numbers of small objects can waste memory • Can also increase memory bandwidth requirements
• OO programming style tend to encourage a large numbers of small methods
• This is good for code readability maintainability etc. • This can be bad for performance
• Very small basic blocks restricts the ability of the compiler to optimise code
• Function calls take time to execute (many machine instructions)
• Large numbers of arguments will increase the overhead
• Virtual functions also need to dereference the vtable
Method In-lining
• Method In-lining is therefore a particularly significant
optimisation for OO codes
• However in many codes most of the performance gain will be from in-lining a small number of critical methods
• Compilers find method in-lining hard • Multi-level in-lining is even harder
• Compilers usually in-line where they can
• The C++ in-line keyword encourages the compiler to attempt in- lining but it is no guarantee
In-line inhibitors
• Compilers will typically only in-line small simple methods
• Which is fine as the relative cost of the function call is less for large methods
• Set/get methods usually OK
• Watch out for small complex methods
• Loops and conditionals may inhibit in-lining
• May be worth replacing short loops with repeated lines
• Virtual functions cannot be in-lined because each call must dereference the vtable pointer
• May be a problem even if you never actually write a sub-class
• Private or Final methods cannot be overridden and are more likely
• JITs may conditionally in-line the most commonly used version or identify methods that are never overidden.
to be in-lined
• In C++ nested templates are sometimes used to avoid the need for deep in-lining
• Nested templates can sometimes be used instead of several levels of inheritance
• However only a single class is generated
• Compiler is free to inline methods from one template into an
• Templates can also be parameterised by constants (e.g. array sizes) As each different parameter results in a different class compiler has more opportunities to optimise.
enclosing one
Constructors
• The new operator allocates storage space
• Constructors are essentially specialised methods used to initialise the contents of the allocated space and convert it into a proper object
• This includes initialising any Vtable pointer
• Note a valid Vtable pointer is needed to identify the class of an object
• Multiple constructors may be called for a single object
• Constructor is called for each ancestor class (constructor chaining)
• Different constructors may call each other
• This can make object creation expensive
Object Creation in Java
• Object Creation is expensive in Java
• Space is allocated on the heap, class’s constructor is called, class’s fields are initiated
• Object’s status is tracked for the garbage collector, garbage collection may occur
• You can see this to some extent when single stepping though object creation using a debugger.
• Avoid creating objects in frequently used routines where performance is important
• Pass in reusable objects as parameters where possible
• Consider defining the operations as a method on an existing result object.
Constructors in C++
• Object create/delete overhead is particularly bad in C++
• Howeverthedefaultconstructors(usedifnoconstructorsaredefined explicitly) are often significantly faster.
• Destructors are also chained
• When one object is simply assigned to another a “copy-
constructor” is called
• Not an issue in Java as there objects are manipulated by reference, nearest equivalent is the clone method
• Same applies to functions that return objects
• Return Value Optimisation should help if the following syntax is used • return Constructor( …);
• AlternativesyntaxavailablebutC++operatoroverloadingencourages functions that return objects
Exceptions
• Throwing an exception is expensive as the program has to backtrack up the call tree looking for a matching try/catch block
• Try and only use in exceptional circumstances
• There will also be some cost to entering a try/catch
• Though this is probably similar to that for a subroutine call
Exceptions in Java
• Creating an exceptions is particularly expensive
• Constructs a full stack trace
• Throwing an exception is also expensive
• Although less so than creating one.
• Try and avoid these in time critical code sections
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com