After sending the email below, I scanned the guile-devel archives, and I see Thomas Morley talking about Lilypond performance. The example program he offers up caught my eye: nested deep in a loop is this:
(eval-string "'(a b c)") Well -- oh -- ha -- I think this is the same culprit that is one of my significant bottlenecks. Although I'm mixing C++ and guile very intensely, my main C++-calling-into-guile is more-or-less eval-string. (its actually scm_eval_string() for me). So I think that I can call and and return from scm_eval_string() about 40K/sec on a five-year-old vintage machine, passing it some trivial thing to evaluate. (Python is in a similar ballpark, if that provides any motivation.) I'll bet, given Thomas' comments, that scm_eval_string() was thinner and faster on guile-1.8.8 Thomas also mentioned the "string problem" ... I recall that, when I looked string handling in the guile-2.1.x codebase, there was a whole lotta pointless conversion back and forth between utf8 and double-byte wide chars. It was just tangled, for no good technical reason. Code read like a bleary-eyed 3AM coding session, with "obvious" inefficiencies in it. Fixing it seemed "easy"; there's no comp-sci in it, nothing subtle. It was mostly just a tangle of spaghetti trying to handle locales every which by by converting .. too many times. I thought I might fix that but I got .. busy doing other things. This might be an unfair complaint, as it might very well be fixed in guile-2.2 or guile-2.9 but ... if there is a string problem, the impression that strings are slow, I suggest that an audit of the string handling code may well reveal that the excessive conversions are still there. In particular, I think the excessive string-conversion code showed up in guile-2.0 and got worse in 2.2 as broader utf8 support was added ... (I also humbly suggest that the guile internals should be 100% utf8. >From long experience, utf8 is amazingly clean and simple, and all the other encoding schemes are just horrid messes of hacks and ick and needless complexity and confusing confusion.) -- Linas On Wed, Dec 5, 2018 at 9:56 PM Linas Vepstas <linasveps...@gmail.com> wrote: > > So I pulled guile-2.9.1(beta) today, and gave it a spin. Looks > good/great! One bug -- some crazy multithreading bug, > reported as #33641 > > My use case: guile calling C++ code, which calls guile, which > calls C, ad nauseum. I have some 133 unit tests, of which > maybe 3/4ths tweak guile in some way. All but the > multi-threading pass, so happy! > > Some comments about performance in this crazy-quilt > mixed environment. Most of code, both guile and C/C++ > is fairly "thin", not doing a whole lot, before transitioning > into the other language. Thus, the performance is dominated > by the cost of the switch. > > There are two different switches: from C++ to guile, and > from guile to C++. For the first, I'm seeing a rate of about > 30K switches/sec C++ into guile (and back, this includes the return). > > Calls going the other way are about 800K switches/sec > from guile into C++ (this also includes the return). This is > on a 2014-vintage machine. > > Clearly a big difference between the two. Many years ago, > I profiled this, but don't recall the results. The profile did not > reveal anything I could control very much or at all. > > Thus, In this scenario, I don't really expect the gnu lightning > bytecode to affect performance very much; I'm mostly > bottlnecked in the switching of environments. > > FWIW, I'm seeing speedups of 1x to 1.5x for interpreted > mode, and 1.3x to 2x for compiled code. Don't read too > much into these numbers: They're crazy mixes of calls > going in both directions. But still, that's really quite good, > all things considered! > > -- Linas > > I cc'ed both guile-user and guile-devel; I'm not subscribed > to guile-devel, but also I did not see a 2.9.1-beta announce > on guile-user! > -- > cassette tapes - analog TV - film cameras - you -- cassette tapes - analog TV - film cameras - you
