Miss All Sunday

Suki's lovely rants, code and One Piece theories

« previous next »
Pages: [1]   Go Down
  • Suki | Reading articles about php performance
    January 21, 2012, 12:13:18 PM
    OK, after clearing my mind with other stuff I decided to start over with this one, I've been reading some articles a bout performance but every article says different things, for example, some articles tell me that this is ugly and not recommended:

    $foo = new foo();
    $var = $foo->some_property;

    and should use a method instead:

    $var = $foo->get('some_property');

    however, Google code tells the contrary:

    http://code.google.com/speed/articles/optimizing-php.html



    Another thing is, I want to implement a $context var that will store all possible comments and another var for status, that way I can re-use that variable in other areas, this work great with small arrays, however, what could possible happen if you have an enormous array?

    let's say, you have 2,000 members and each member has an average of 50 status, now each status has an average of 20 comments:

    2,000 x 50 = 100,000

    50 x 30 = 1,500

    having an array with 100,000 values and each value is an array with at least 5 other values as well, granted, most of those values are ints, still, the data is huge.

    Interesting reading: http://nikic.github.com/2011/12/12/How-big-are-PHP-arrays-really-Hint-BIG.html

    Reading that article (I didn't understand all of it :P)  I found:  http://php.net/SplFixedArray

    which I can use since I only manage integers as keys, however, the size of the array still concerns me and I haven't find any other method, query that table every time I want a value is out of the picture here.

    I been reading other articles as well but those are just too generic and doesn't quite apply to what I'm after.

    Does having a separate table for storing only IDs could help?  I mean I will still have the large array, however, it will only contain integers and I can then perform checks on this array for validation:

    if (in_array($id, $large_array))
       $status->Delete($id);


    I also want to implement some other features that are server intensive like a notification system.

    All of that will be implemented on all kind of server configurations, thus, whatever method I implement has to work on a large variety of servers :(


    If I don't build solid grounds then I won't be able to build on top of that ground or if I built it will be just too unstable, :(
  • Suki | Re: Reading articles about php performance
    January 21, 2012, 02:06:59 PM
    Further thoughts on this:

    What could happen if we, instead of working with a huge array, slice this huge array into small chunks, lets say, 100 status and 100 comments, and then we only "work"  with this array with only 100 items instead of dealing with 100,000 items...

    Yes the table still will be huge, however, the query can be made to only fetch the las 100 items and cache the result (1 minute or even less), of course the cache will be re-generated when a user adds/delete a status/comment.

    Since status/comments aren't messages on a forum and tend to have a shorter life span I don't see why I cannot work with just the latest data instead of handling all data, if necessary I can build  query to fetch all data from X user but that will just be on specific cases (for example a history page).

    I dunno, it may work, I mean I can even use the same query to build a pagination system and avoid the need to build yet another query just for the pagination.
Pages: [1]   Go Up
« previous next »