Hasan Aljudy wrote:
> Pragma wrote:
>> John Reimer wrote:
>>
>> Now, if you want to see something *really slick* for commenting, take a look at JackSlocum's site:
>>
>> http://www.jackslocum.com/blog/2006/10/09/my-wordpress-comments-system-built-with-yahoo-ui-and-yahooext/ 
>>
>>
>> It's pretty script-heavy, but it shows what can be done with AJAX and a solid widget set.  Be sure to check out the "Documentation" section too.
>>
> 
> That baby is too slow ... my FF2 had to suffer before opening it ..

The Django book has the same commenting system but it's a lot faster:

http://www.djangobook.com/en/beta/chapter14/

Julio César Carrascal Urquijo wrote:

> Hasan Aljudy wrote:
>> Pragma wrote:
>>> John Reimer wrote:
>  >>
>>> Now, if you want to see something *really slick* for commenting, take a look at JackSlocum's site:
>>>
>>>
http://www.jackslocum.com/blog/2006/10/09/my-wordpress-comments-system-built-with-yahoo-ui-and-yahooext/
>>>
>>>
>>> It's pretty script-heavy, but it shows what can be done with AJAX and a solid widget set.  Be sure to check out the "Documentation" section too.
>>>
>> 
>> That baby is too slow ... my FF2 had to suffer before opening it ..
> 
> The Django book has the same commenting system but it's a lot faster:
> 
> http://www.djangobook.com/en/beta/chapter14/

This one also worked fine with Konqueror, that other link must do something weird then.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Julio César Carrascal Urquijo wrote:
> Hasan Aljudy wrote:
>> Pragma wrote:
>>> John Reimer wrote:
>>>
>>> Now, if you want to see something *really slick* for commenting, take a look at JackSlocum's site:
>>>
>>> http://www.jackslocum.com/blog/2006/10/09/my-wordpress-comments-system-built-with-yahoo-ui-and-yahooext/
>>>
>>>
>>> It's pretty script-heavy, but it shows what can be done with AJAX and a solid widget set.  Be sure to check out the "Documentation" section too.
>>>
>>
>> That baby is too slow ... my FF2 had to suffer before opening it ..
> 
> The Django book has the same commenting system but it's a lot faster:
> 
> http://www.djangobook.com/en/beta/chapter14/

Wow, that is *really slick*

Brad Anderson wrote:
> Julio César Carrascal Urquijo wrote:
> 
>>Hasan Aljudy wrote:
>>
>>>Pragma wrote:
>>>
>>>>John Reimer wrote:
>>>>
>>>>Now, if you want to see something *really slick* for commenting, take
>>>>a look at JackSlocum's site:
>>>>
>>>>http://www.jackslocum.com/blog/2006/10/09/my-wordpress-comments-system-built-with-yahoo-ui-and-yahooext/
>>>>
>>>>
>>>>It's pretty script-heavy, but it shows what can be done with AJAX and
>>>>a solid widget set.  Be sure to check out the "Documentation" section
>>>>too.
>>>>
>>>
>>>That baby is too slow ... my FF2 had to suffer before opening it ..
>>
>>The Django book has the same commenting system but it's a lot faster:
>>
>>http://www.djangobook.com/en/beta/chapter14/
> 
> 
> Wow, that is *really slick*

That's exactly what's needed for the D spec pages.  The "Comments" link is nice, but usually the comments one wants to make are like "the *foo in this code should be just foo".  And many people don't even realize the Comments page is there as it is.  Too easy to miss.

--bb

Craig Black wrote:
> I don't see why D doesn't use nedmalloc for its non-GC malloc implementation.  This would allow expert developers that avoid GC in certain situations glean the best performance possible.

The user could do this quite easily himself.  Just create a D header module for the malloc calls and use them instead of std.c.stdlib.malloc, etc.


Sean

Perhaps.  But why not do this by default and spare everyone the headache?

-Craig

"Sean Kelly" <sean@f4.ca> wrote in message news:el75b4$1ho3$2@digitaldaemon.com...
> Craig Black wrote:
>> I don't see why D doesn't use nedmalloc for its non-GC malloc implementation.  This would allow expert developers that avoid GC in certain situations glean the best performance possible.
>
> The user could do this quite easily himself.  Just create a D header module for the malloc calls and use them instead of std.c.stdlib.malloc, etc.
>
>
> Sean

I modified the C++ that was written to reflect the D code more closely:
And now DMD is slightly faster than VS2003 without nedmalloc.

Has anyone managed to compile nedmalloc under DMC?

I don't believe this is a good test, but anyway here it is.

And as I said before D is great and I'll continue using it everyday.

Zz

Results:
----------------------------------------------
VS2003:
Element count: 1000000

ContextSwitches - 122127
First level fills = 0
Second level fills = 0

ETime(   0:00:05.921 ) UTime(   0:00:05.687 ) KTime(   0:00:00.171 )
ITime(   0:00:05.296 )

----------------------------------------------
VS2003 With nedmalloc:
Element count: 1000000

ContextSwitches - 52979
First level fills = 0
Second level fills = 0

ETime(   0:00:02.593 ) UTime(   0:00:02.562 ) KTime(   0:00:00.062 )
ITime(   0:00:02.328 )

----------------------------------------------
DMD:
Element count: 1000000

ContextSwitches - 118191
First level fills = 0
Second level fills = 0

ETime(   0:00:05.281 ) UTime(   0:00:05.203 ) KTime(   0:00:00.031 )
ITime(   0:00:04.875 )

----------------------------------------------
C++ Code:
#include <iostream>
#include <string>
#include <memory>
#include <boost/ptr_container/ptr_vector.hpp>
#include "nedmalloc.h"

void* operator new(size_t sz)
{
	void* m = nedmalloc(sz);
	if(!m) puts("out of memory");
	return m;
}

void operator delete(void* m)
{
	nedfree(m);
}

class cpp_element
{
public:
	std::string Creator;
	std::string CreationDate;
	std::string Label;
};

class cpp_root
{
public:
	boost::ptr_vector<cpp_element> elements;
};


int main(int argc, char* argv[])
{
	cpp_root* _root = new cpp_root();
	std::auto_ptr<cpp_root> root(_root);

	std::string cd1 = "AAAAAAAAAAAAAAAAAAAAAAAAA";
	std::string cd2 = "BBBBBBBBBBBBBBBBBBBBBBBBB";
	std::string cd3 = "CCCCCCCCCCCCCCCCCCCCCCCCC";

	for(int i = 0; i < 1000000; i++)
	{
		cpp_element* element = new cpp_element();

		element->CreationDate = cd1 + "cd1";
		element->Creator      = cd2 + "cd2";
		element->Label        = cd3 + "cd3";

		root->elements.push_back(element);
	}

	printf("Element count: %d\n", root->elements.size());

	return 0;
}


----------------------------------------------
D Code:
module test;
import std.stdio;

class d_element
{
public:
	char[] Creator;
	char[] CreationDate;
	char[] Label;
}

class d_root
{
public:
	d_element[] elements;
}

int main()
{
	char[] cd1 = "AAAAAAAAAAAAAAAAAAAAAAAAA";
	char[] cd2 = "BBBBBBBBBBBBBBBBBBBBBBBBB";
	char[] cd3 = "CCCCCCCCCCCCCCCCCCCCCCCCC";
	
	d_root root = new d_root();
	
	for(int i = 0; i < 1000000; i++)
	{
		d_element element = new d_element();
		element.CreationDate = cd1 ~= "cd1";
		element.Creator      = cd2 ~= "cd2";
		element.Label        = cd3 ~= "cd3";
		root.elements ~= element;
	}

	printf("Element count: %d\n", root.elements.length);	
	return 0;
}

zz wrote:
>         cpp_element* element = new cpp_element();
> 
>         element->CreationDate = cd1 + "cd1";
>         element->Creator      = cd2 + "cd2";
>         element->Label        = cd3 + "cd3";
<snip>
>         d_element element = new d_element();
>         element.CreationDate = cd1 ~= "cd1";
>         element.Creator      = cd2 ~= "cd2";
>         element.Label        = cd3 ~= "cd3";

I don't think those lines are really equivalent. Hint: write the last element in the list to output, in both versions. You might notice a difference :).

Frits van Bommel wrote:
> zz wrote:
> 
>>         cpp_element* element = new cpp_element();
>>
>>         element->CreationDate = cd1 + "cd1";
>>         element->Creator      = cd2 + "cd2";
>>         element->Label        = cd3 + "cd3";
> 
> <snip>
> 
>>         d_element element = new d_element();
>>         element.CreationDate = cd1 ~= "cd1";
>>         element.Creator      = cd2 ~= "cd2";
>>         element.Label        = cd3 ~= "cd3";
> 
> 
> I don't think those lines are really equivalent. Hint: write the last element in the list to output, in both versions. You might notice a difference :).

Ouch. That was really silly of me (Didn't notice it).
It should have been element.CreationDate = cd ~ "cd1" and yes it would make a difference.

What I had yesterday was using cd1.dup, didn't notice the silly mistake when making the change.

After fixing this problem here are my results on a different machine.

From my point of view these tests are not really nessesary on my side since I still continue using D and I belive that someday the memory stuff will be optimized.

Zz

-------------------------------------------------------
VS2003
Element count: 1000000

ContextSwitches - 24787
First level fills = 0
Second level fills = 0

ETime(   0:00:05.328 ) UTime(   0:00:05.046 ) KTime(   0:00:00.187 )
ITime(   0:00:04.828 )

-------------------------------------------------------
VS2003 with nedmalloc
Element count: 1000000

ContextSwitches - 8854
First level fills = 0
Second level fills = 0

ETime(   0:00:02.390 ) UTime(   0:00:02.218 ) KTime(   0:00:00.078 )
ITime(   0:00:02.015 )

-------------------------------------------------------
DMC
Element count: 1000000

ContextSwitches - 35008
First level fills = 0
Second level fills = 0

ETime(   0:00:07.312 ) UTime(   0:00:07.000 ) KTime(   0:00:00.031 )
ITime(   0:00:06.656 )

D change:
	for(int i = 0; i < 1000000; i++)
	{
		d_element element = new d_element();
		element.CreationDate = cd1 ~ "cd1";
		element.Creator      = cd2 ~ "cd2";
		element.Label        = cd3 ~ "cd3";
		root.elements ~= element;
	}

zz wrote:
> 
>  From my point of view these tests are not really nessesary on my side since I still continue using D and I belive that someday the memory stuff will be optimized.

It will, but the changes will happen sooner if particular use cases are brought up as problematic.  Particularly if tweaks can be made here and there to improve performance without writing an entirely new garbage collector.  That said, I have considered writing a GC more targeted at concurrent programming than the current implementation (basically an improved version of Hoard with mark/sweep collection added), but doing so would take time I don't have at the moment.  Maybe sometime after 1.0.


Sean