Not referencing the issue in the commit message makes it harder to find the 
issue in the tracker.  After a few patchy runs It appears like this change may 
cause a massive impact on performance at least for a Guile-1.8 based 
compilation.  A patchy run on a mostly unloaded machine previously took about 
40 minutes on my computer.  Now it appears to be more like 52 minutes.  
Considering that non-trivial amounts of time also get spent by GCC and 
Ghostscript, that seems rather troubling.  Have you benchmarked the Guile-1.8 
case (where performance problems may be less masked by startup times etc)?

If we can verify that on a Guile-1.8 compilation the slow-down is like this 
(I'd guess that the slowdown when reduced to just the LilyPond contribution 
could be about 30%), I think we should not include a version of this in 2.21.0 
but release at least one unstable version without it so that actual users have 
a chance to report slowdowns in case they reappear.

I don't think this patch actually fixes any Guile-2 problem when viewed against 
the _current_ version of master as opposed to what was in master when you 
designed it?


---

** [issues:#5741] Parse inline scheme using per-expression port**

**Status:** Fixed
**Labels:** Fixed_2_21_0 
**Created:** Fri Feb 07, 2020 02:52 PM UTC by Han-Wen Nienhuys
**Last Updated:** Sat Feb 22, 2020 11:29 AM UTC
**Owner:** Han-Wen Nienhuys


Introduces a throw-away string port, Overlay_string_port, which makes
a port out of a random section of a C string.  It does not own the
string, so there is no overhead in creating and discarding the ports
during parse time.

For GUILE v2, Overlay_string_port uses UTF-8 encoding, so UTF-8
encoded string constants within the Scheme constants are interpreted
as Unicode correctly.

This obviates the string port that Source_file carries along.

This commit fixes a problem with GUILE 2.2.6, where LilyPond
calculates offsets in the source file as bytes, while GUILE interprets
the source file as UTF-8 encoded Unicode. As a result, files with
Unicode before embedded scheme break completely.

https://codereview.appspot.com/557330043


---

Sent from sourceforge.net because testlilyissues-a...@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/testlilyissues/issues/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/testlilyissues/admin/issues/options.  Or, if this is 
a mailing list, you can unsubscribe from the mailing list.
_______________________________________________
Testlilyissues-auto mailing list
testlilyissues-a...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
  • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
  • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
  • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
  • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
  • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
  • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
  • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
  • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
  • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
  • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development
  • ... Auto mailings of changes to Lily Issues via Testlilyissues-auto via Automated messages for lilypond development

Reply via email to