Mail Archives: cygwin/2002/03/19/01:50:38
Just a curiousity...
I've a mental concept I've been batting around for a while - about how can we drastically increase configure and related script performance on cygwin...
AFAICT the largest performance issue is fork() and exec(). File access is quite fast, as is networking. Unix sockets are a go slow given Ralf's testing :p but that's about it.
So, what I'm thinking could be done is:
Create a new shell. For the most common current causes of fork()/exec(), make those commands internal. Specifically, make all expression evaluation (such as `basename foo`) done in-process (i.e. C-style code:{save_context();evalute (expression);pop_context(result);}, only spawning commands where they are not internal. (Currently, AFAIK, ash and bash use sub-shells quite commonly).
Now that would be a maintenance and coding nightmare - repeating lots of other folk's work, and having to get bug compatability as well.... no thanks.
What if, instead of rewriting all those helper commands, we
*) Make each one into a library - ie cygshellbasename0.dll. - with a well-defined interface (say execute (int argc, char **argv), AND no ABI changes!
*) Replace the current binary with a façade that uses the .dll.
*) in the shell, look for the library *before* calling the binary, thus saving a spawn()
*) Ideally, adapt an existing shell rather than starting new (I'm not a reinvent-ze-wheel) kinda guy.
Now I imagine that if done _properly_ the upstream authors won't object too much to librarization, so the amount of code to be written is significantly shrunk.
I've not seen a specific project to accomplish this (in google/freshmeat/sourceforge) - but I figure that cygwin is _such_ a prime platform for it that if one exists, and I'd be repeating work, I'll find someone who knows it here....
Anyway, this is (obviously) a long-term proposition, but if two or three folk from here would be interested in collaborating on such a project...
Cheers,
Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -