Op 30-07-13 16:01, wxjmfa...@gmail.com schreef: > > I am pretty sure that once you have typed your 127504 > ascii characters, you are very happy the buffer of your > editor does not waste time in reencoding the buffer as > soon as you enter an €, the 125505th char. Sorry, I wanted > to say z instead of euro, just to show that backspacing the > last char and reentering a new char implies twice a reencoding.
Using a single string as an editor buffer is a bad idea in python for the simple reason that strings are immutable. So adding characters would mean continuously copying the string buffer into a new string with the next character added. Copying 127504 characters into a new string will not make that much of a difference whether the octets are just copied to octets or are unpacked into 32 bit words. > Somebody wrote "FSR" is just an optimization. Yes, but in case > of an editor à la FSR, this optimization take place everytime you > enter a char. Your poor editor, in fact the FSR, is finally > spending its time in optimizing and finally it optimizes nothing. > (It is even worse). Even if you would do it this way, it would *not* take place every time you enter a char. Once your buffer would contain a wide character, it would just need to convert the single character that is added after each keystroke. It would not need to convert the whole buffer after each key stroke. > If you type correctly a z instead of an €, it is not necessary > to reencode the buffer. Problem, you do you know that you do > not have to reencode? simple just check it, and by just checking > it wastes time to test it you have to optimized or not and hurt > a little bit more what is supposed to be an optimization. Your scenario is totally unrealistic. First of all because of the immutable nature of python strings, second because you suggest that real time usage would result in frequent conversions which is highly unlikely. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
