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] 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] 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 nel...@seznam.cz 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
