Re: A no brainer...
| From: | Richard Lynch | Date: | Tue, 17 Oct 2006 17:35:24 +0000 |
| Subject: | Re: A no brainer... | ||
| References: | 1 2 3 4 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-243258@lists.php.net to get a copy of this message | ||
On Mon, October 16, 2006 9:43 pm, Larry Garfield wrote:
>> I suspect that serialization overhead is trivial for scalar data,
>> and
>> only starts to kill you when one starts schlepping bloated OOP
>> structures or arrays back and forth -- at which point you messed up
>> your architecture, and the serialization performance is just a
>> symptom, not the disease.
>
> Yes, serialization is trivial for scalar data. However, to use a
> real-world
> example, the Drupal CMS allows users to define an unlimited number of
> path
> aliases. They're just key/value mappings, one string to another. Any
> given
> page can have dozens of links on it, which means dozens of mappings.
> The
> database table is really just a simple two column table, user path to
> system
> path.
>
> In older versions, the system pulled the whole table out at once and
> built a
> look up array, once per page. Only one query per page, but it meant a
> lot of
> data to pull and build. On sites with lots of aliases, that got very
> slow.
> So the latest version now pulls records one at a time. But that's a
> ton of
> SQL queries, many of which simply find no data in the first place. So
> now
> there's talk of building the look up table one record at a time and
> caching
> that, but the serialization/deserialization costs there are
> non-trivial when
> you're talking about a large array.
>
> The balance is still being worked out. :-) I'm just pointing out that
> no
> matter how you slice it, there is no free lunch performance-wise when
> you
> need to store data. The right balance will depend greatly on your use
> case.
One Idea:
Pull all the records in one query at first request and keep the
$result around -- but don't walk through the whole thing. *DO* sort
the records by the input value with an ORDER BY on an indexed field.
Now, to find an actual lookup, use a binary search with mysql_seek()
and cache any lookup results in an array.
Not sure it will be faster, but run some benchmarks and see. :-)
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?