Comments on: My programming pattern maxim http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml You tell that other boy, not to touch the woodwork... Thu, 28 Aug 2008 18:39:38 +0000 http://wordpress.org/?v=2.7-hemorrhage hourly 1 By: Shawn Lauriat http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml#comment-36825 Shawn Lauriat Fri, 02 Mar 2007 03:50:31 +0000 http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml#comment-36825 "My point is that any one of those reasons is a workaround againt needing the Flyweight pattern which is why, in practice, the pattern is extremely rare in the PHP world. One of the only patterns more rare is the double check lock pattern (for obvious reasons I hope)." Okay, that makes sense, then. And yes, very obvious... :-) “My point is that any one of those reasons is a workaround againt needing the Flyweight pattern which is why, in practice, the pattern is extremely rare in the PHP world. One of the only patterns more rare is the double check lock pattern (for obvious reasons I hope).”

Okay, that makes sense, then. And yes, very obvious… :-)

]]> By: tychay http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml#comment-36819 tychay Fri, 02 Mar 2007 03:46:01 +0000 http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml#comment-36819 @Shawn: My point is that any one of those reasons is a workaround againt needing the Flyweight pattern which is why, in practice, the pattern is extremely rare in the PHP world. One of the only patterns more rare is the double check lock pattern (for obvious reasons I hope). @Mike: There are performance issues and memory issues for objects in PHP4, but I suspect that version isn't an issue with this particular client. With SPL you can make an object behave a lot like an array except during export. Be sure to run APD or XDebug on the app with profiling mode on.This will generate valgrind file which will show you where the slowdown is. Optimizing blind is a very bad thing. If they are a Zend shop (they’re not), there are tools in Zend Studio for this. Remember it’s a really bad idea to do in PHP what has already been solved better somewhere else. PHP is a glue language, it isn’t an all-in-one language like Ruby or Java. @Shawn: My point is that any one of those reasons is a workaround againt needing the Flyweight pattern which is why, in practice, the pattern is extremely rare in the PHP world. One of the only patterns more rare is the double check lock pattern (for obvious reasons I hope).

@Mike:
There are performance issues and memory issues for objects in PHP4, but I suspect that version isn’t an issue with this particular client. With SPL you can make an object behave a lot like an array except during export.

Be sure to run APD or XDebug on the app with profiling mode on.This will generate valgrind file which will show you where the slowdown is. Optimizing blind is a very bad thing. If they are a Zend shop (they’re not), there are tools in Zend Studio for this.

Remember it’s a really bad idea to do in PHP what has already been solved better somewhere else. PHP is a glue language, it isn’t an all-in-one language like Ruby or Java.

]]> By: Shawn Lauriat http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml#comment-36796 Shawn Lauriat Fri, 02 Mar 2007 02:27:45 +0000 http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml#comment-36796 Michael, As far as performance and memory control, the Advanced PHP Debugger has done wonders for me in tracking down issues. I've found that most of the issues I've run across in performance have stemmed from out of control recursion, filesystem calls, database interaction, or library functions that simply run faster if you hand-code them in PHP instead. Your mileage may vary, but I would say that the difference between using objects or arrays should really lie in what you instead to do with the data they'll hold rather than the performance implications of each option. Michael,

As far as performance and memory control, the Advanced PHP Debugger has done wonders for me in tracking down issues. I’ve found that most of the issues I’ve run across in performance have stemmed from out of control recursion, filesystem calls, database interaction, or library functions that simply run faster if you hand-code them in PHP instead.

Your mileage may vary, but I would say that the difference between using objects or arrays should really lie in what you instead to do with the data they’ll hold rather than the performance implications of each option.

]]> By: Michael http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml#comment-36633 Michael Thu, 01 Mar 2007 17:05:31 +0000 http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml#comment-36633 Thanks for the info Terry and Shawn. I wasn't kidding when I said that I might be writing PHP soon. I might be re-writing an existing Java app that is pure middleware in PHP. This app is used by > 10 million users daily and is part of a company that is very well known for its use of PHP. They wrote it in Java about four years ago and say it scaled pretty well up to around 10 million daily users. They don't think it will scale up another order of magnitude because it is stateful. So they figured if they were going to re-write it to be stateless, then PHP was the way to go. So it's really good to know PHP's strengths and weaknesses. Are there performance issues around using objects in PHP, or is it more of a matter of taste to use things like associate arrays and what not in place of objects? In Java, just the opposite is (generally) true. Thanks for the info Terry and Shawn. I wasn’t kidding when I said that I might be writing PHP soon. I might be re-writing an existing Java app that is pure middleware in PHP. This app is used by > 10 million users daily and is part of a company that is very well known for its use of PHP. They wrote it in Java about four years ago and say it scaled pretty well up to around 10 million daily users. They don’t think it will scale up another order of magnitude because it is stateful. So they figured if they were going to re-write it to be stateless, then PHP was the way to go.

So it’s really good to know PHP’s strengths and weaknesses. Are there performance issues around using objects in PHP, or is it more of a matter of taste to use things like associate arrays and what not in place of objects? In Java, just the opposite is (generally) true.

]]> By: Shawn Lauriat http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml#comment-36468 Shawn Lauriat Thu, 01 Mar 2007 03:50:15 +0000 http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml#comment-36468 I use the flyweight pattern in my project at work (http://www-306.ibm.com/software/awdtools/buildforge/enterprise/) and it has actually helped. When dealing with massive amounts of data it cuts down quite a bit on memory usage. That said, I don't use it that much, and I didn't need a name for the "make managing lots of objects in a single hit not suck" pattern. While here, might as well respond: 1. Using objects means not only using the data, but the behavior the data inherits elsewhere. Flywheels of database objects can definitely help in specific cases. 2. I completely agree. 3. I disagree. PHP gets used mostly to glue browsers to databases, but as someone who codes a comparatively large application in PHP, it can get used however you want to use it, to sound completely redundant. I would definitely say it didn't get designed for it originally, but you can code a complex application in PHP without wishing for another language's features. 4. Well, yeah... 5. I agree with separation of layers, but you can have each of the layers in PHP. What kind of things in particular have you had to push onto Java? Can you give an example? I use the flyweight pattern in my project at work (http://www-306.ibm.com/software/awdtools/buildforge/enterprise/) and it has actually helped. When dealing with massive amounts of data it cuts down quite a bit on memory usage.

That said, I don’t use it that much, and I didn’t need a name for the “make managing lots of objects in a single hit not suck” pattern.

While here, might as well respond:

1. Using objects means not only using the data, but the behavior the data inherits elsewhere. Flywheels of database objects can definitely help in specific cases.

2. I completely agree.

3. I disagree. PHP gets used mostly to glue browsers to databases, but as someone who codes a comparatively large application in PHP, it can get used however you want to use it, to sound completely redundant. I would definitely say it didn’t get designed for it originally, but you can code a complex application in PHP without wishing for another language’s features.

4. Well, yeah…

5. I agree with separation of layers, but you can have each of the layers in PHP. What kind of things in particular have you had to push onto Java? Can you give an example?

]]> By: tychay http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml#comment-36344 tychay Wed, 28 Feb 2007 18:36:58 +0000 http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml#comment-36344 @Michael: Yeah because powering sites like Yahoo!, Facebook, Wikipedia, etc. doesn’t impress. :-) The reason Flyweight may be very useful in a language like Java and not that useful in PHP is because Java can be multiple threaded and requests can be long lived and reused. In PHP, the latter isn’t possible and the former shouldn’t be true (PHP is slow and abusive). Also Java uses objects for everything. In PHP, arrays (hashes) occupy a unique state that no amount of SPL will change. (Can you var_export() an object?) Here is my example: 1) Why use objects at all? Just use an array (bind to property by reference) and move the work to the client class (there is only one). 2) You would probably not load so many photos at a time in a single PHP process. (You can see how Facebook limits the total number of photos per album and Flickr always paginates output no matter what you are viewing). 3) Just because the metadata is separated and reused in your database during normalization, doesn't mean it has to be reused in PHP. Remember PHP is a glue language that is essentially user-facing so it’s representations work best when they are perceived the way the user sees them. 4) Separate it into two server side queries (one for the photo essentials and one fot the metadata). The latter only gets requested on user action (like a mouseover or a page view). 5) The standard PHP approach: move the hard work to a different layer. (The most common layer is the database itself, but even at Tagged we use a lot of Java for the stuff PHP does shitty.) @Michael:

Yeah because powering sites like Yahoo!, Facebook, Wikipedia, etc. doesn’t impress. :-)

The reason Flyweight may be very useful in a language like Java and not that useful in PHP is because Java can be multiple threaded and requests can be long lived and reused. In PHP, the latter isn’t possible and the former shouldn’t be true (PHP is slow and abusive).

Also Java uses objects for everything. In PHP, arrays (hashes) occupy a unique state that no amount of SPL will change. (Can you var_export() an object?)

Here is my example:

1) Why use objects at all? Just use an array (bind to property by reference) and move the work to the client class (there is only one).

2) You would probably not load so many photos at a time in a single PHP process. (You can see how Facebook limits the total number of photos per album and Flickr always paginates output no matter what you are viewing).

3) Just because the metadata is separated and reused in your database during normalization, doesn’t mean it has to be reused in PHP. Remember PHP is a glue language that is essentially user-facing so it’s representations work best when they are perceived the way the user sees them.

4) Separate it into two server side queries (one for the photo essentials and one fot the metadata). The latter only gets requested on user action (like a mouseover or a page view).

5) The standard PHP approach: move the hard work to a different layer. (The most common layer is the database itself, but even at Tagged we use a lot of Java for the stuff PHP does shitty.)

]]> By: Michael http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml#comment-36291 Michael Wed, 28 Feb 2007 15:42:54 +0000 http://terrychay.com/blog/article/my-programming-pattern-maxim.shtml#comment-36291 PHP and Design Patterns? Wouldn't that imply PHP and design? That does not compute... I have to rip on PHP while I can since I might wind up programming in it soon. Flyweight is great for a lot of caching scenarios. At my company, we have a couple of dozen canonical datatypes in our system, like photos, videos, contacts, favorites, etc. We have a very rich metadata model for each one of these guys. So if a user logs in a views their photos, each photo not only has all of its particular data like it's name, URL, geometry, camera used for taking it, etc. but also a lot of metadata that is common to any photos. In good OOD, this photo metadata should accessed as part of the photo. So this was an obvious flyweight situation. We cached the metadata and then when building a photo (uh oh another pattern there) a pointer to the metadata is passed. Of course the actual photo only exposes read-only accessors to the metadata.The metadata itself wasn't that expensive in terms of memory usage, but it is created by parsing an XML file stored in a database. It wouldn't make any sense to go through that process for every photo on the site. So what would be the PHP way of doing this? Keep the metadata separate from the object instances? Is it difficult to keep shared data around for the lifetime of an application as opposed to a request or a session? PHP and Design Patterns? Wouldn’t that imply PHP and design? That does not compute… I have to rip on PHP while I can since I might wind up programming in it soon.

Flyweight is great for a lot of caching scenarios. At my company, we have a couple of dozen canonical datatypes in our system, like photos, videos, contacts, favorites, etc. We have a very rich metadata model for each one of these guys. So if a user logs in a views their photos, each photo not only has all of its particular data like it’s name, URL, geometry, camera used for taking it, etc. but also a lot of metadata that is common to any photos. In good OOD, this photo metadata should accessed as part of the photo. So this was an obvious flyweight situation. We cached the metadata and then when building a photo (uh oh another pattern there) a pointer to the metadata is passed. Of course the actual photo only exposes read-only accessors to the metadata.The metadata itself wasn’t that expensive in terms of memory usage, but it is created by parsing an XML file stored in a database. It wouldn’t make any sense to go through that process for every photo on the site.

So what would be the PHP way of doing this? Keep the metadata separate from the object instances? Is it difficult to keep shared data around for the lifetime of an application as opposed to a request or a session?

]]>