Re: [fonc] Incentives and Metrics for Infrastructure vs. Functionality
On Thu, Jan 03, 2013 at 01:07:55AM +0100, Loup Vaillant-David wrote: > On Tue, Jan 01, 2013 at 11:18:29PM +0100, Ondřej Bílka wrote: > > On Tue, Jan 01, 2013 at 09:12:07PM +0100, Loup Vaillant-David wrote: > > > > > > void latin1_to_utf8(std::string & s); > > > > > Let me guess. They do it to save cycles caused by allocation of new > > string. > > > instead of > > > > > > std::string utf8_of_latin1(std::string s) > > > or > > > std::string utf8_of_latin1(const std::string & s) > > You may have guessed right. But then, *they* guessed wrong. I often se how people blindly use performance related suggestions. Here it was that passing structure by reference is faster than by value. (which is now sometimes false.) > > First, the program in which I saw this conversion routine is dead slow > anyway. If they really cared about the performance of a few encoding > conversion, they should have started by unifying string handling to > begin with (there are 6 string types in the program, all actively > used, and sometimes converted back and forth). > > Second, every time the conversion does actually do anything, the utf8 > string will be longer than the original one, and require a realloc() > anyway (unless they wrote some very clever code, but the overall > quality of their monstrosity makes it unlikely). > > Finally, I often needed to write this: > > std::string temp = compute_text(); > latin1_to_utf8(temp); > call_function(temp); > > Which does not reduce allocations in the slightest, compared to > > call_function(utf8_of_latin1(compute_text())); > > My version may even be a bit more amenable to optimisation by the > compiler. (In addition to be more readable, I dare say.) > > So, they *may* have made this move because they cared about > performance. A more likely explanation though, is that they simply > thought "oh, I need to convert some strings to utf8", and > transliterated that in C++. They could have thought "oh, I need utf8 > versions of some strings" instead, but that would be functional > thinking. > > Loup. > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Incentives and Metrics for Infrastructure vs. Functionality
On Thu, Jan 03, 2013 at 11:33:53AM -0700, Marcus G. Daniels wrote: > On 1/2/13 1:49 AM, Ondřej Bílka wrote: > >A better example is that you have c code where at several places > >is code for inserting element into sorted array and using that > >array. What should you do. CS course taugth us to use red-black > >tree there. Right? Well not exactly. When one looks how is this > >code used it discovers that first occurence is shortest path > >problem so radix heap is appropriate. Second does not use ordering > >so hash table is more appropriate. Third periodicaly generates > >webpage from sorted data so keeping new data in separate buffer > >and calling sort from generating routine looks best. Finally > >fourth, original contains a comment: /* Used to find closest value > >to given value. Profiling shown this accounted to 13% of time. As > >updates are rare (not changed in previous year) using more > >sophisticated structures than binary search is > >counterproductive.*/ > I imagine a process like this: > > First create a generic container type, say a Map, for the array and > a lookup and traversal routine. > > If performance matters, profiling will reveal that certain uses are > more conspicuous than others. Profiling will reveal that you spend 5% time in insert and 3% time in remove. You spend two weeks optimizing your tree and memory allocator for it. > > Inspection of those uses will suggest refinement of the Map to drop > the traversal and/or lookup routines, and thus diversification of > the types to an ordered or unordered sets. Distinguishing between > integer and more expensive comparisons might motivate introduction > of Patricia trees (for integer sets). And thats exactly a problem I am talking about. Person that writes structures will not notice that what he writes is not needed and introduce much more problems by adding patricia trees etc. A person who uses that structure will not notice that he can do it more effectively without these structures because performance details were abstracted away. Note that in my examples each uses some special property that is not worth abstracting because its quite narrow use case. > > Maybe I'm losing sight of the question at hand. I'm just saying > that going maximally generic at first will motivate appropriate > specialization of the abstractions. The opposite approach of > specialized inline implementations, built from scratch in different > apps or even different modules of the same app has a higher risk of > creating frozen accidents. > > Marcus > > > > > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
My point is that you could just Object have methods true,false and nil Any reasonably optimalizing compiler would replace them with bytecode. On Mon, Jun 06, 2011 at 08:05:13PM +0200, Toon Verwaest wrote: > They are parsed just like variables. Rather than finding their declaration > in the method itself they are known to the compiler. Hence pseudovariables. > > It also has the advantage that you don't have to pollute your literal frame > since there are special bytecodes that handle them. > > Cheers, > Toon > On Jun 6, 2011 5:51 PM, "Ondrej Bilka" wrote: > > Hello > > As I started looking at squeak I am puzzled why true,false and nil are > pseudovariables. Why they cannot be just constants like 0,1. > > > > ___ > > fonc mailing list > > fonc@vpri.org > > http://vpri.org/mailman/listinfo/fonc > ___ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] why are true,false,nil pseudovariables
Hello As I started looking at squeak I am puzzled why true,false and nil are pseudovariables. Why they cannot be just constants like 0,1. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
