[PHP] Does class length slow down performance
Hi, I'm developing an joomla component and my helper an user classes are crowing bigger and bigger. The helper class is for static use only. Does class size decrease performance of my php scripts, even for static usage? Is there a general rule when to split a class to keep performance up? Thanks for reply, Sebastian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Does class length slow down performance
On Thu, 2010-07-22 at 10:49 +0200, Sebastian Ewert wrote: Hi, I'm developing an joomla component and my helper an user classes are crowing bigger and bigger. The helper class is for static use only. Does class size decrease performance of my php scripts, even for static usage? Is there a general rule when to split a class to keep performance up? Thanks for reply, Sebastian How big roughly are we talking here? The larger a script or class is, the more memory this uses per instance. Out of the box, PHP doesn't have a way to share the memory space of libraries and classes, so creating massive scripts for a website is not a great idea. The typical approach is to break classes down into blocks such that you need only include per script what you actually need to run that script. For example, having a full class dedicated to user management would need somewhere to create a list of users. Now it doesn't make sense to include this user management class each time you want to create a list of users, so you could split that method off into a different class where it can easily be shared without every script loading in lots of unnecessary code. That's a very simple example, but it can help beforehand if you sketch out exactly what you need to do, and then break it down into logical classes like that. Maybe look at some UML software to help you with this? Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Does class length slow down performance
Ashley Sheridan wrote: On Thu, 2010-07-22 at 10:49 +0200, Sebastian Ewert wrote: Hi, I'm developing an joomla component and my helper an user classes are crowing bigger and bigger. The helper class is for static use only. Does class size decrease performance of my php scripts, even for static usage? Is there a general rule when to split a class to keep performance up? Thanks for reply, Sebastian How big roughly are we talking here? The larger a script or class is, the more memory this uses per instance. Out of the box, PHP doesn't have a way to share the memory space of libraries and classes, so creating massive scripts for a website is not a great idea. The user object contains 850 Lines and about 50 functions. It also implements 2 table-objects (DB Tables). The helper class contains 500 Lines. The typical approach is to break classes down into blocks such that you need only include per script what you actually need to run that script. For example, having a full class dedicated to user management would need somewhere to create a list of users. Now it doesn't make sense to include this user management class each time you want to create a list of users, so you could split that method off into a different class where it can easily be shared without every script loading in lots of unnecessary code. Thats exacty the point. In my user class I have functions whitch return object-lists of diffrent users or strings with html-form elements for managing this user account. But if I put all these in a helper class I would anyway need to implement the user object there, because of the other getter functions (getUserName etc.) and the table-objects. I always thought this would be less effective, because I have more instances of objects. Thanks, Sebastian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Does class length slow down performance
[snip] Thats exacty the point. In my user class I have functions whitch return object-lists of diffrent users or strings with html-form elements for managing this user account. But if I put all these in a helper class I would anyway need to implement the user object there, because of the other getter functions (getUserName etc.) and the table-objects. I always thought this would be less effective, because I have more instances of objects. [/snip] Sounds like a major refactoring is in order, how reusable is your class? There is not enough room in this e-mail to cover the basic and intermediate practices of OO design but it sounds like you may need to re-think your design. Does this class do one thing and only one thing? Does it do it really well? Just from what I am reading I see that we have a user class (getUserName) and that class returns lists of users? It sounds as if to me that the user class talks not only about a single user, but perhaps all of the users (object lists of different users). On the surface that sounds like to classes to me, a user class and a class to manipulate said users. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Does class length slow down performance
Jay Blanchard wrote: [snip] Thats exacty the point. In my user class I have functions whitch return object-lists of diffrent users or strings with html-form elements for managing this user account. But if I put all these in a helper class I would anyway need to implement the user object there, because of the other getter functions (getUserName etc.) and the table-objects. I always thought this would be less effective, because I have more instances of objects. [/snip] Sounds like a major refactoring is in order, how reusable is your class? There is not enough room in this e-mail to cover the basic and intermediate practices of OO design but it sounds like you may need to re-think your design. Does this class do one thing and only one thing? Does it do it really well? Thanks for your advice. I know that I have to go much deeper into programm design. I would appreciate if you could send me some links with practial examples. I've only read some theoretical and very general stuff about it and cannot link everything to the real world. Just from what I am reading I see that we have a user class (getUserName) and that class returns lists of users? It sounds as if to me that the user class talks not only about a single user, but perhaps all of the users (object lists of different users). That was just to generalize things. My user class only returns informations for one user. These informations are values of db-fields or generated html strings. But other classes like my message class have functions that return lists of instances of their own class. From what you've written I think its better to extract these functions into helper classes. But if you want to get all messages that refer to one specific msg its better to leave that function in the message class, isn't it? Or if you want to get a list with all friends of a specific user?(friends are not implemented yet) On the surface that sounds like to classes to me, a user class and a class to manipulate said users. But back to my first Problem: Is a class with 850 lines to long? If it is should I take all the html genarating functions and put them in a helper class? If I do so and there is no way to call those functions without initalizing the main user object, will there still be an increase of performance? Thanks, Sebastian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Does class length slow down performance
On 22 July 2010 15:27, Sebastian Ewert seb2...@yahoo.de wrote: Jay Blanchard wrote: [snip] Thats exacty the point. In my user class I have functions whitch return object-lists of diffrent users or strings with html-form elements for managing this user account. But if I put all these in a helper class I would anyway need to implement the user object there, because of the other getter functions (getUserName etc.) and the table-objects. I always thought this would be less effective, because I have more instances of objects. [/snip] Sounds like a major refactoring is in order, how reusable is your class? There is not enough room in this e-mail to cover the basic and intermediate practices of OO design but it sounds like you may need to re-think your design. Does this class do one thing and only one thing? Does it do it really well? Thanks for your advice. I know that I have to go much deeper into programm design. I would appreciate if you could send me some links with practial examples. I've only read some theoretical and very general stuff about it and cannot link everything to the real world. Just from what I am reading I see that we have a user class (getUserName) and that class returns lists of users? It sounds as if to me that the user class talks not only about a single user, but perhaps all of the users (object lists of different users). That was just to generalize things. My user class only returns informations for one user. These informations are values of db-fields or generated html strings. But other classes like my message class have functions that return lists of instances of their own class. From what you've written I think its better to extract these functions into helper classes. But if you want to get all messages that refer to one specific msg its better to leave that function in the message class, isn't it? Or if you want to get a list with all friends of a specific user?(friends are not implemented yet) On the surface that sounds like to classes to me, a user class and a class to manipulate said users. But back to my first Problem: Is a class with 850 lines to long? If it is should I take all the html genarating functions and put them in a helper class? If I do so and there is no way to call those functions without initalizing the main user object, will there still be an increase of performance? It's unlikely to cause you performance problems unless you've got a huge amount of traffic - and then you could probably fix your problems easier than refactoring classes. Personal anecdote: I've worked on classes longer than 3K lines with no marked performance problem. That doesn't mean I recommend it, though: bigger classes are a pain to maintain as you loose overview of what's in the class. Regards Peter -- hype WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Does class length slow down performance
Peter Lind wrote: It's unlikely to cause you performance problems unless you've got a huge amount of traffic - and then you could probably fix your problems easier than refactoring classes. Personal anecdote: I've worked on classes longer than 3K lines with no marked performance problem. That doesn't mean I recommend it, though: bigger classes are a pain to maintain as you loose overview of what's in the class. Regards Peter So you think that a length of 850 lines won't lead to a performance problem? The site is not online yet. I just wanted to know when to split a class and if there are performance problems with to long classes. Thanks, Sebastian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Does class length slow down performance
On 22 July 2010 15:49, Sebastian Ewert seb2...@yahoo.de wrote: Peter Lind wrote: It's unlikely to cause you performance problems unless you've got a huge amount of traffic - and then you could probably fix your problems easier than refactoring classes. Personal anecdote: I've worked on classes longer than 3K lines with no marked performance problem. That doesn't mean I recommend it, though: bigger classes are a pain to maintain as you loose overview of what's in the class. Regards Peter So you think that a length of 850 lines won't lead to a performance problem? The site is not online yet. I just wanted to know when to split a class and if there are performance problems with to long classes. No, I don't think there will be problems. I also think the only way you'll ever find out whether it *will* be a problem in your system is by testing. Regards Peter -- hype WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Does class length slow down performance
[snip] So you think that a length of 850 lines won't lead to a performance problem? No, I don't think there will be problems. I also think the only way you'll ever find out whether it *will* be a problem in your system is by testing. [/snip] ^this to the max [snip] The site is not online yet. I just wanted to know when to split a class and if there are performance problems with to long classes. [/snip] I will try to find some good links for you but there is one book that I can whole-heartedly recommend (I have all of my younger, um, less experienced programmers read it); Head First Object-Oriented Analysis and Design http://oreilly.com/catalog/9780596008673/ It is a quick read, the exercises are fun and even though they focus on Java the principles apply across al OOP languages. As for splitting a class it doesn't matter the size of the class as long as the class does one thing and does it really well. We have some very large classes (remember - you are trying to describe an object and all of the methods for that object) and some very small (under 25 lines including comments) classes. The one characteristic that sticks out is that they all do one thing really well. http://www.wdvl.com/Authoring/Scripting/Tutorial/objects.html (I am starting you a few pages into the article) is a good basic discussion of OOP. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Does class length slow down performance
No, I don't think there will be problems. I also think the only way you'll ever find out whether it *will* be a problem in your system is by testing. I've started some benchmarks with apachebench but the problem is I don't have any benchmarks to compare with. And so I started looking for something to change. I will try to find some good links for you but there is one book that I can whole-heartedly recommend (I have all of my younger, um, less experienced programmers read it); Head First Object-Oriented Analysis and Design http://oreilly.com/catalog/9780596008673/ Thanks to all. My question is answered and I have some lecture for the next week. Greets, Sebastian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Does class length slow down performance
On Thu, Jul 22, 2010 at 2:40 AM, Ashley Sheridan a...@ashleysheridan.co.ukwrote: The larger a script or class is, the more memory this uses per instance. This is not quite true. When the script is loaded, it requires a fixed amount of memory to parse it. The larger it is, the more memory it requires. Next, the script itself is executed, running any top-level code (not in a class or global function). If that includes any require/include statements, those scripts are loaded (if necessary). If it creates objects, that takes more memory. However, the size of each instance of the class is affected only by the data it stores--not the number or length of its methods. PHP creates a single internal Class object to contain the methods, and this indeed takes memory proportional to the number of methods, but this doesn't affect the instances. Each instance stores only its instance properties such as $this-firstName. This correction aside, the advice here is spot on: split your classes based on responsibilities. The reason for this has more to do with ease of development than performance. Say you have one monster class filled with static methods. If your application uses most of those methods for each request, splitting it will have no performance benefit because both scripts will end up being loaded anyway. But if you can group the methods into logical subsystems, they will be easier to understand and work with. Peace, David
