Public SourceMage Discussion List

[Dufflebunk <dufflebunk AT dufflebunk.homeip.net>]

This is unlikely to happen. The amount of time spent in, say, cast
compared to actually compiling is insignificant. The slow spots mainly
consist of the searching functions, which are held back by disk access,
and stuff that relies heavily on liblock, which is slowly being
rewritten.

There have been many arguments and discussions about language change,
one of the ideas was a hybrid solution to use more than one language.
Most people felt in those discussions that more than one language would
make starting to work on the scripts/programs much more difficult. Then
there are the problems with updating, things have to be compiled and
installed. If you want to make some changes you might need to compile
again.

The fact is, if a chunk is slow because it's in bash, it is written
wrong. Take libdepends as an example. It was my strongest case for a
hybrid solution. It was slow, it took several minutes to order
dependencies. It was very complicated, and no one wanted to touch it
(even the author, me). It was written wrong. It was rewritten and now is
fast and much simpler (>800 lines down to 450, doesn't use 2 500 line
support libs). It used directed non-cyclic graphs to resolve and order
dependancies. I argued that that sort of thing could not be written
efficiently in Bash (and I still say that) so it was necessary to change
languages or write some stuff in another language which could handle the
constructs I wanted. However, I had simply solved the problem the wrong
way. Now it doesn't do any of that, it uses make. A tool that is already
on all systems and is very stable and was designed to do exactly what I
wanted.

The moral of that story isn't that a binary came to the rescue, because
there have been other times where a binary wasn't used when a section
was rewritten, but that chunks that are slower than they should be are
most likely written wrong.

The second main reason for a chunk being slow is liblock. liblock is
slowly being rewritten to be much faster. It has the problem that it has
a tight wait loop which would consume all CPU if it didn't have a sleep,
and the smallest it can sleep for is 1 second. I am rewriting it to use
signals, and I hope to get it into an IPC form so different parts can
talk to each other properly.

This is a long email, and I just got up so I'm still sleepy. I think I
covered what I wanted to say... but I may have just meandered around for
a page and completely missed the point. 


On Sat, 2003-06-28 at 10:29, Eric Sesterhenn wrote:
> Hi,
> 
> sorrow and I where thinking about reimplementing some slow sorcery functions
> in C, by starting replacing slow stuff from /var/lib/sorcery/modules with a
> wrapper like
> "function oldfunc () { spellbook oldfunc; }"
> where "spellbook" would be a compiled binary, thus getting some speed into
> this stuff. We would also volunteer in doing this. The idea is not to 
> replace
> the entire scripts with a binary but just some slow stuff. We got to this
> idea, when sorrow implemented a "gaze size" and xiticix's python example was
> much faster than the bash implementation, but I think forcing everybody to 
> use
> python is not a good idea, so what do you think about this idea?
> 
>  cu Eric/snakebyte