that be critical mainly for the TP queue I guess, the rest of them (1,2,4 in my list) is quite macroscopic
actually some of the ideas floating around could result in improvements: - multithreading: interpreter in its own thread without being lockstepped by task has upside potential (on modern CPU's that is) - Jospeh's work (executing a program off an abstract syntax tree, not by reinterpreting source): speedup potential (plus improved diagnostics and static optimization potential, but that's a different issue) I realize my note on _setup size was kind of a sledgehammer argument, sorry -m Am 13.04.2012 um 03:49 schrieb Jon Elson: > Kenneth Lerman wrote: >> I guess your style is more subtle than mine. >> >> I think I would just record everything whether or not it changed. >> Hmmm... if we store 1000 bytes at each step for a million (executed) >> line program. That's "only" a gig. Small potatoes by today's standards. >> > Remember that this stuff has to be processed in near-real time. > Anything that greatly slows > down the interpreter or trajectory planner is not going to be seen as a > universal improvement. > > Jon > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
