On Fri, 3 Dec 2010 20:56:45 -0500 Mike Blumenkrantz <m...@zentific.com> said:
> > i think we're confusing 2 issues. 1 is moving from O(n2) to O(n) and having > > a mainloop that handles lots of fd's at all vs a a micro-optimisation patch > > on top of it that makes very little difference at all. yes - it does malloc > > less. yes it will fragment less. yes it is a bit faster. the code is > > shorter. not disputed. > > > > the question is - is that patch on top "part of the original O(n2) -> O(n) > > work or is it separate. i'm on the fence. it could have gone in as part of > > mikez's work and no one would have peeped. at the same time the code it > > implements for a list is very different to everything else in ecore that > > uses lists. i don't see a technical problem with the code in the patch - > > more of a clarity issue that you see something wanting to be a list and not > > actually using normal list infra. chances are this bit of ecore isnt going > > to see much work over time - so is that actually an issue? all good > > questions. i'm tempted to say "just let it in as it'd have been fine were > > it part of the original O(n2) -> O(n) fix". > > > I think a lot of people are confusing my saying "O(n) behavior needs to be > fixed" with "this patch needs to be in now." With some testing to make sure > that it works with recursive main loops and whatnot I don't see an issue, but > I am not saying that it must be committed this second if the consensus is > that it should wait. i think this patch should go live in purgatory for the moment (purgatory == wait for 1.1 development to begin and then get merged). that's my position on it. its an improvement. it just happened to be unlucky to not be part of your O (n) stuff and be separated at birth. to be honest - i think the mainloop itself should really be left the hell alone atm - your O(n) stuff is "tolerated" because its such a good improvement for large #'s of fd's. but fact is.. ecore wasn't built for that and hasn't been for many years. not against it being improved, but being improved at the last minute is a pretty risky thing. it's risking years of "we know it works". -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
