|
Chris Meech wrote: The slower they work, the better.
Because there are soooo maaaany ways to improve! Imagine if customer would get used to "the 2.5h" routine, and after few weeks or even better months they would show him your "2sec" one? WOW!
--
"My software never has bugs. It just develops random features."
|
|
|
|
|
You're doing it wrong. First you give them the 2.5h routine. then you give them a free update that trims it to an even 2 hours. After that you offer to sell them the latest version that drops that time to about 15 minutes. the rest of the speed improvement you save until a later time when you can add it in to make up for the lack of genuine improvements in a release.
I guess I've spent way too much time around marketing executives for my own good.
|
|
|
|
|
I've written some code that turned out to be dog slow when given sufficiently-large data sets. Usually I've tried to fix it before the customer could try it and complain. It's not always easy, though, to know what things are going to pose a problem until one actually codes them. Obviously O(n^2) algorithms are likely to cause problems unless 'n' is bounded to a small value, but it may not be possible to recognize an algorithm which takes time c+kn as an obvious bottleneck without testing it on large data sets. For example, if c==1000k the program may seem to take the same amount of time with n=10 and n=100, but be unacceptably slow with n=1,000,000. It may well be that the n=100 case is much more common, but if the n=1,000,000 case could occur the system needs to be able to deal with it without causing timeouts.
|
|
|
|
|
Yeah, the code is AIDS but maybe it was an afterthought. Everybody writes stupid code once in a while. Maybe the coder just didn't care at the moment.
I didn't get any requirements for the signature
|
|
|
|
|
How about simply bagging the non-translatable list (which was probably only put there as a lame fix to the performance of his clunky lookup) and using the DataSet and DataTable, etc. classes to parse the XML?
|
|
|
|
|
What is the point of
if (node.Attributes["Publish"].InnerText.Trim().Contains(s))
{
return;
} A check for containting a single letter and then doing nothing?
Also,
public static ArrayList NonTranslatable
{
get
{
nonTranslatable.Add("1st String");
nonTranslatable.Add("2nd String");
nonTranslatable.Add("30th String");
return nonTranslatable;
}
} Sorry, but WTF is this ****?
Who the hell adds elements to a collection in the getter?
And where do the strings come from?
From a DB? When are they checked? When is determined if something is non-translatable?
foreach (DictionaryEntry de in translationDictionary)
{
if (de.Key.ToString().Equals(node.Attributes["Publish"].InnerText.Trim()))
node.Attributes["Publish"].InnerText
= translationDictionary[node.Attributes["Publish"].InnerText.Trim()].ToString();
}
I never used a SortedList, you can access its elements with the DictionaryEntry class, is there any difference to a dictionary?
Timothy Byrd wrote: Simply putting an if (nonTranslatable.Count == 0) block around the code in the NonTranslatable property took the run time down from >75 minutes to ~30 seconds. (Fun fact: During the 75 minutes of processing, those repeated Add() calls caused the program to take up about 25MB of extra memory. That's a lot of strings to loop through and compare repeatedly. OMG )
Wow.
Timothy Byrd wrote: Not to mention all the calls to Trim() inside the loop. Or does the runtime optimize those out as invariant?
Maybe the XML contains trailing spaces?
Unless you trim them, the XML Nodes' InnerText wouldn't equal the DictionaryEntries with same key.
Anyway, I feel truly sorry for you...
|
|
|
|
|
Megidolaon wrote: What is the point of
if (node.Attributes["Publish"].InnerText.Trim().Contains(s))
{
return;
}
A check for containting a single letter and then doing nothing?
No, that loop checks if the node text contains one of the non-translatable strings and if so, bails.
Megidolaon wrote: Maybe the XML contains trailing spaces?
Unless you trim them, the XML Nodes' InnerText wouldn't equal the DictionaryEntries with same
You are correct, however within a given call to TranslateNode(), the xml node stays the same. Until it gets translated from the dictionary. Oh crap, there's yet another bug in there that I hadn't noticed - it can double translate.
Anyway, the phrase node.Attributes["Publish"].InnerText.Trim() should be invariant, and I assume it takes some processing. So a line like:
string xmlText = node.Attributes["Publish"].InnerText.Trim();
and then refering to that string wold have been more efficient,and easier for me to read, I think.
-- T
|
|
|
|
|
I am updating an asp.net application developed by someone else to use master pages, and I was getting a NullReferenceException with the following lines:
Line 61: }
Line 62: if (IsRequiredField('<%= txtExpDate.ClientID %>', 'Expiry Date', errorLbl) == false)
Line 63: if (f.value==1)
After some time to figure out what was happening, I found this perfect way to clear asp.net controls :
private void ClearFields()
{
this.txtCouponCode.Text="";
this.txtCouponName.Text="";
this.txtDiscount.Text="";
this.txtNoUses.Text="";
this.ddlNoUses.SelectedIndex=1;
this.txtExpDate=null;
}
|
|
|
|
|
Came across the following code during a peer code review :
if (x == 0)
{
y = 0;
}
else
{
y = x;
}
Interesting, isn't it!
Asad
|
|
|
|
|
Very prosaic.
P.S. And only counts as one statement anyway.
modified on Monday, December 29, 2008 2:07 PM
|
|
|
|
|
Interesting.
Not a word that comes to mind when reading that.
|
|
|
|
|
this seems to be one of the most common horrors' posted here and also one of the most common I come across...
|
|
|
|
|
Yeah, most so calld horrors are just verbose code that wouldn't even get optimized for speed by writing it in less lines.
I mean it's fine to write in fewer ines but this isn't actually wrong...
|
|
|
|
|
don't waste unnecessary assignment cycles, especially when you get payed by the line:
if (x == 0)
{
if (y != 0)
{
y = 0;
}
}
else
{
if (y != x)
{
y = x;
}
}
|
|
|
|
|
There are some seriously twisted people on here.
Larry Miller
|
|
|
|
|
If x and y are simple variables of matching type, the code is pretty nonsensical. There are some situations, however, where such code could save a tiny bit of time, and others where its behavior could be slightly different from 'y=x'.
For example of the former situation, suppose that 'x' is an integer and 'y' is a double, and 99.9% of the time 'x' will equal zero. If one were to code 'y=x' the computer would always perform a library call to do the integer-to-double promotion. Even if the library routine did an early-exit check for a value of zero, calling the library in the first place would still add overhead which the above code would eliminate.
As for the second situation, if 'x' and 'y' are of a numeric type where two variables may both test equal to zero and yet not have identical representations (true of some floating-point implementations), code like the above may be useful to ensure that only one form of zero is used. For example, consider the following, on an implementation that features positive and negative zero, and positive and negative infinity:
{
double x1,x2,z1,z2;
x1= 1e-30/1e30;
x2=-1e-30/1e30;
z1=1/x1;
z2=1/x2;
}
Note that x1==0 and x2==0, but (1/x1)!=(1/x2). Forcing x1 and x2 to the same zero would ensure that (1/x1)==(1/x2).
|
|
|
|
|
I always do ...
switch (x)
{
case 0 : y = 0; break;
case 1 : y = 1; break;
case 2 : y = 2; break;
...
...
}
... for Int32
|
|
|
|
|
u r jerk
Ravie Busie
Coding is my birth-right and bugs are part of feature my code has!
|
|
|
|
|
Rauhotz wrote: I always do ...
switch (x)
{
case 0 : y = 0; break;
case 1 : y = 1; break;
case 2 : y = 2; break;
...
...
}
At last you forgot to write default case.
default: y = x;
Do not trust a computer...
Always check what computer is doing
regards,
Divyang Mithaiwala
Software Engineer
|
|
|
|
|
I found this in JS:
function toggleDiv(divName)
{
$(divName).toggle();
}
So using the shortcut: toggleDiv('foo'); , we would end up with 17 characters.
Using the unusual long version: $('foo').toggle(); , we would end up with 18 characters.
|
|
|
|
|
perhaps the coder has a non-functioning $ key? :P
|
|
|
|
|
That's very considerate of you!
|
|
|
|
|
It's sad, but I've seen those kind of things so many times I hardly consider them horrible anymore.
|
|
|
|
|
Does user hate to see so many '$' on the screen ?
|
|
|
|
|
Unfortunately you have to use the function nearly 50 times before it actually saves any keystrokes...
|
|
|
|