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
On Mon, October 16, 2006 8:20 pm, Roman Neuhauser wrote:
> So no, it makes no sense for a database to be faster than
> filesystem.
The database may, or may not, have finely-tuned a lot of things to
write their records more quickly/efficiently than the PHP approach of
writing individual fil
Hi Guys :) I'm off today, so I'll follow-up with you tomorrow.
Meanwhile, have a great day :)
-Ed
On Oct 17, 2006, at 2:20 AM, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2006-10-16 16:40:34 -0700:
On Oct 16, 2006, at 6:20 PM, Roman Neuhauser wrote:
Modern filesystems cope well wit
# [EMAIL PROTECTED] / 2006-10-16 16:40:34 -0700:
>
> On Oct 16, 2006, at 6:20 PM, Roman Neuhauser wrote:
> >Modern filesystems cope well with large directories (plus it's
> >quite trivial to derive a directory hierarchy from the
> >filenames). Looking at the numbers produced by timi
On Monday 16 October 2006 14:11, Richard Lynch 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 serializ
On Oct 16, 2006, at 6:20 PM, Roman Neuhauser wrote:
Modern filesystems cope well with large directories (plus it's
quite
trivial to derive a directory hierarchy from the filenames).
Looking at the numbers produced by timing various operations in
a directory with exactly 100,000
# [EMAIL PROTECTED] / 2006-10-15 16:54:29 -0700:
>
> On Oct 15, 2006, at 3:27 PM, Tony Di Croce wrote:
>
> >Wow... well, I was certainly not speaking from direct experience,
> >only from what seemed to make sense to me. This tells me that their
> >is some serious room for improvement in PHP d
On Oct 16, 2006, at 1:03 PM, Richard Lynch wrote:
My thesis is that choosing SOLELY on raw performance without regard to
security, scalability is silly, and it's particularly silly on sites
that get so little traffic that "raw performance" tests and benchmarks
are rendered meaningless.
I that
On Mon, October 16, 2006 2:44 pm, Ed Lazor wrote:
>> Almost ALL of this is moot for any but the hardest-hit sites -- So
>> choosing your session store based solely on performance for a
>> boutique
>> store is just plain silly.
>
> You don't have to be one of the hardest-hit sites to benefit. I
> w
Almost ALL of this is moot for any but the hardest-hit sites -- So
choosing your session store based solely on performance for a boutique
store is just plain silly.
You don't have to be one of the hardest-hit sites to benefit. I
won't go so far as to say that all sites benefit, but even the
On Sat, October 14, 2006 5:57 pm, Ed Lazor wrote:
>
> On Oct 14, 2006, at 10:00 AM, Tony Di Croce wrote:
>
>> I think that the cost of de-serializing a session stored in files
>> should be significantly LESS than the cost of doing so through a
>> database, for the following reasons:
>>
>> 1) The db
On Oct 15, 2006, at 3:27 PM, Tony Di Croce wrote:
Wow... well, I was certainly not speaking from direct experience,
only from what seemed to make sense to me. This tells me that their
is some serious room for improvement in PHP de-serialization code...
Well, kinda. Hard disks are a lot sl
Wow... well, I was certainly not speaking from direct experience, only from
what seemed to make sense to me. This tells me that their is some serious
room for improvement in PHP de-serialization code...
td
Sorry Tony, I should have been more clear. I already know that
storing session data
On Oct 14, 2006, at 10:00 AM, Tony Di Croce wrote:
I think that the cost of de-serializing a session stored in files
should be significantly LESS than the cost of doing so through a
database, for the following reasons:
1) The db will need to parse querys. Not an issue for files.
2) The ses
On Saturday 14 October 2006 11:02, Ed Lazor wrote:
> > Of course, the cost of serialization and deserialization is non-
> > trivial for
> > any data structure that is of interesting size, and you have to
> > keep in mind
> > that if you aren't syncing to the database periodically then you
> > will
Of course, the cost of serialization and deserialization is non-
trivial for
any data structure that is of interesting size, and you have to
keep in mind
that if you aren't syncing to the database periodically then you
will end up
with stale data objects. (An issue in any case, but the long
On Friday 13 October 2006 20:18, Tony Di Croce wrote:
> Is their a slick way of automatically serializing Objects to the session
> when a script exit()'s and de-serialize them in session_start()?
>
> It seems to me that object oriented PHP might actually be useful if I could
> persist an object acr
Is their a slick way of automatically serializing Objects to the session
when a script exit()'s and de-serialize them in session_start()?
It seems to me that object oriented PHP might actually be useful if I could
persist an object across an entire session, and come to think of it, their
really o
18 matches
Mail list logo
