Hi,
That is very peculiar... it should never be slower than an
implementation in PHP - unless your algorithm isn't optimal.
Depends on your definition of "optimal".
In setting up the structures, I have a linear search going to find the
node for a parent. That's why it gets slower for (very)
Brian Moon schrieb:
> Well, making a custom Phorum extension is a whole other discussion for
> our team to have. If we went down that road, we would do more than just
> this function.
An extension that provides efficient graph / tree algorithms (the latter
are just a special case of the former)
Maurice Makaay wrote:
Hi,
A quick sketch of an idea that should work:
Yes, that would work. The problem though, is that there's still
accumulation of data going on, before the actual sorting can take place.
Remember that the main reason for writing the C-extension was to get the
memory usage
Richard Lynch wrote:
Seems like you could just make it a custom extension and see if people
use it a lot...
Even if you just had every phorum user asking for it, that would drive
a lot of interest, no?
Well, making a custom Phorum extension is a whole other discussion for
our team to have. I
> If his cache had no locking before, what changed?
Well, I have been using several cache classes. A good cache class is the
pear cache light.
This cache is serializing your data and write this data to a file - of
course with file locking.
I could imagine, that a improved serialize-function coul
On Wed, May 9, 2007 9:22 am, Brian Moon wrote:
> A common issue in lots of applications is tree sorting with unlimited
> depth. Phorum has used a recursive function since 1999 to solve this
> problem. However, at MySQL Conference this year, we finally wrote a
> non
Seems like you could just make
Derick Rethans wrote:
On Wed, 9 May 2007, Maurice Makaay wrote:
At a really
large number of nodes, the extension becomes slower, but the memory stays low.
That is very peculiar... it should never be slower than an
implementation in PHP - unless your algorithm isn't optimal.
Me too. But, f
On Wed, 9 May 2007, Maurice Makaay wrote:
> At a really
> large number of nodes, the extension becomes slower, but the memory stays low.
That is very peculiar... it should never be slower than an
implementation in PHP - unless your algorithm isn't optimal.
regards,
Derick
--
PHP Internals - P
Hi,
A quick sketch of an idea that should work:
Yes, that would work. The problem though, is that there's still
accumulation of data going on, before the actual sorting can take place.
Remember that the main reason for writing the C-extension was to get the
memory usage down.
Here's some ben
Hi,
A quick sketch of an idea that should work:
1, 'parent_id'=>0),
array('id'=>2, 'parent_id'=>1),
array('id'=>3, 'parent_id'=>1),
array('id'=>4, 'parent_id'=>2)
);
// create column data
$keys=$indents=$index=array();
$i=0;
foreach($nodes as $node)
{
$id=$node['id'];
$pid=
Hello,
Take a look at
http://www.php.net/manual/en/function.array-multisort.php#68689
/ http://rquadling.php1h.com/array_multisort_column.php
Could you please explain how you think that multisort array would help
in doing a tree sort? AFAIK, tree sorting is not a simple sort algorithm
where yo
On 09/05/07, Brian Moon <[EMAIL PROTECTED]> wrote:
A common issue in lots of applications is tree sorting with unlimited
depth. Phorum has used a recursive function since 1999 to solve this
problem. However, at MySQL Conference this year, we finally wrote a non
recursive function for it and ach
A common issue in lots of applications is tree sorting with unlimited
depth. Phorum has used a recursive function since 1999 to solve this
problem. However, at MySQL Conference this year, we finally wrote a non
recursive function for it and acheived both memory and time savings on
very large
As I mentioned a few days ago (I see the thread has been very active since so
not sure people will remember) is that we'll try and take a deeper look at phar
and some of the issues we raised. Also looking at this in parallel makes a lot
of sense. We shouldn't be married to a specific implementat
> -Original Message-
> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
>
> I guess we are solving the wrong problem. We have:
> 1. phar needs script-defined named streams
> 2. Named streams are prohibited by some config option
> 3. Let's pretend this stream is not actually what it is
>
> From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
>> ...and phar is the best candidate I know for this.
>
> I'd say the only one
NO, there is an alternate PHP package format. It solves every issues you
rose about phar (including the direct url access to a virtual file). Its
name is PHK and
On 08/05/07, Richard Lynch <[EMAIL PROTECTED]> wrote:
On Tue, May 8, 2007 9:13 am, David Santinoli wrote:
> If there's enough interest in this, I will rework the patch according
> to
> Sara's hint.
I'd have to be +1 on making more than just the 2 hashes available for
this feature, though if it's
On 5/9/07, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Hello Pierre,
Tuesday, May 8, 2007, 10:59:08 PM, you wrote:
> On 5/8/07, Davey Shafik <[EMAIL PROTECTED]> wrote:
>> Stanislav Malyshev wrote:
>> >> No, not "in other words". I said the words I said, because I meant
>> >> those words. I'm talk
18 matches
Mail list logo
