On Thu, Dec 2, 2010 at 10:20 PM, Mike Blumenkrantz <m...@zentific.com> wrote: > On Thu, 2 Dec 2010 13:18:02 +0100 > Cedric BAIL <cedric.b...@free.fr> wrote: >> On Thu, Dec 2, 2010 at 1:08 PM, Iván Briano (Sachiel) >> <sachi...@gmail.com> wrote: >> > 2010/12/2 Mike McCormack <mj.mccorm...@samsung.com>: >> >> On 12/02/2010 08:20 PM, Lucas De Marchi wrote: >> >>> On Thu, Dec 2, 2010 at 8:34 AM, Cedric BAIL<cedric.b...@free.fr> wrote: >> >>>> On Thu, Dec 2, 2010 at 7:22 AM, Mike McCormack<mj.mccorm...@samsung.com> >> >>>> wrote: >> >>>>> Rather than using malloc'ed list entries in the mail loop, use a single >> >>>>> linked in-place list. >> >>>>> >> >>>>> This avoid lots of mallocs and frees as the main loop iterates. >> >>>> >> >>>> I like the idea, but I fear that doing change to the core main loop >> >>>> structure could break things. Maybe we should post pone this change to >> >>>> 1.1. From my point of view we already did to much change to ecore main >> >>>> loop during the beta cycle. >> >>> >> >>> I agree. >> >>> >> >>> How long are we for 1.0 release? >> >> >> >> Come on guys. >> >> >> >> The only reason that you're seeing this is that I don't commit directly to >> >> SVN. >> >> >> >> This is a tweak on fixes that have been put in by others in the last few >> >> days. If you object to this, please read the SVN commits list and object >> >> to the other patches in the same area. >> > >> > True, all the refactoring of fd handlers was a big enough thing to put >> > off until 1.1, >> > and it was done directly in SVN. So what's the reason to not commit >> > this one now? >> >> I know I should have objected at that time, but I didn't. Right now I >> think we already have to much change in the ecore main loop to feel >> safe with all possible scenario (glib integration, multiple ecore main >> loop imbrication and all) that I would really prefer to postpone more >> change in this aread. But that's just my opinion. If you really want >> to do it, wait at least for beta3 to be released tomorrow.
> This change absolutely must go through before 1.0 if we want to have a > respectable main loop, and the following data will prove it. This data can > easily be replicated using the client/server_bench.c files in ecore/examples. > > ecore revision 54616: > ======================= > 25000 fd test: > Connection lost! #10400! > ^C > Time elapsed for 25000 connections: 371.606825 seconds > # specimen experiment time starting time ending time > 1 645014268 3993714 649007982 > ./bench_client 4.38s user 0.70s system 1% cpu 6:11.76 total > (Note: at this point I killed it because after 10400 fds, ecore stopped > and no longer processed any connections) <snip> > ecore revision HEAD: > ======================= > 25000 fd test with printf disabled: > Time elapsed for 25000 connections: 1.141623 seconds > # specimen experiment time starting time ending time > 1 1136243319 3866130 1140109449 > ./bench_client 0.43s user 0.91s system 98% cpu 1.356 total <snip> > 25000 fd test with Mike's newest patch: > Time elapsed for 25000 connections: 1.131604 seconds > # specimen experiment time starting time ending time > 1 1127458798 3833513 1131292311 > ./bench_client 0.43s user 0.91s system 99% cpu 1.345 total > > Again, a clear, though smaller, improvement. Regardless of whether this > specific patch makes it into 1.0, our policy here should definitely not be > "how > fast can we revert the work on ecore?", it should be "how fast and efficiently > can we test/fix this issue to make sure it's working as intended?" because > it's > definitely a bug. I beg to differ. In fact you are right for the first case, it was a bug, from unusable to usable. So that's fine. But new patch from Mike isn't, it's from fast to faster and it doesn't use Eina_Inlist, but it's own implementation. It also does touch a lot of logic inside ecore main loop, much more than what I would like for a beta cycle. So if that patch is not for fixing a bug, I would really prefer to postpone it. And as you guys are playing with ecore, we have still some report related to it that should be fixed for the release. It would be good if you could take care of them :-) Thanks, -- Cedric BAIL ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
