|
Doctors are at a loss as to its cause [^], but ms engineers say that if they're not soon given instructions on what to make next, they may have to fall back to just fixing bugs.
Your prayer is needed.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
|
Sander Rossel wrote: New icons to replace the new icons
MS has spent millions of dollars on icon creation over the years. Which, is just crazy to me.
people like their icons, I guess.
|
|
|
|
|
It's less crazy when you consider that one of the most successful IT companies is a lot about form and less about function.
People love form, first impressions and all that.
I'm talking about Apple, of course.
See it like this, if it wouldn't return the investment they wouldn't do it.
And to be fair, they do have a lot of icons so costs are automatically high.
New icons have a practical use as well, it helps in keeping different versions apart.
You should check the comments here, someone posted the icons of VS 2005 to 2017: VS 2017 RTM icon is not contrast enough on some backgrounds - Developer Community[^]
Good stuff
|
|
|
|
|
Sander Rossel wrote: VS 2017 RTM icon is not contrast enough on some backgrounds - Developer Community[^] No-one suggested using Resource Hacker [^] to change the icons?
It's easy as pie; just open the main exe in RH (after taking a panic-back-up copy), then:- Select the icon in the list of resources
- choose Action > Replace icon
- Click the Open file with new icon button
- Navigate to the main exe of the version of VS whose icons you prefer, and open it
- Pick the icon you want, and save (it automatically does all sizes).
It's been the same process since at least XP, and it ain't exactly rocket surgery.
I have to do it every time Xplorer2 updates, because I hate the bright orange icon that comes with the Ultimate version.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I doubt they know how to fix bugs...
Anything that is unrelated to elephants is irrelephant Anonymous
- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944
- Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
|
|
|
|
|
I know the problem.
It ain't like riding a bike -- if you don't do something for a long time, you forget how to do it.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
(I was torn between putting these here or in the C# forum, but it not really a serious question...)
Given a simple string
const string _str = "abcdefghijklmnopqrstuvwxyz";
put the following equivalent code blocks in order of their speed:
if ( _str.Contains("~")) {....}
if ( _str.Contains('~')) {....}
if ( _str.IndexOf("~") >= 0) {....}
if ( _str.IndexOf('~') >= 0) {....}
if ( _str.IndexOf("~", StringComparison.Ordinal) >= 0) {....}
Hint: there are three tiers --- One is the clear winning. Two others are about the same, significantly behind, and the last two are about the same, way behind the others.
Truth,
James
|
|
|
|
|
I did cheat, and run a quick console app.
But D seems fastest, very closely followed by B. Barely really.
Then A, and behind A is E.
Slowest is C.
|
|
|
|
|
Hmmmm Very interesting results.
I ran my test using BenchmarkDotNet, with a longer string, with a "~" near the end.
Now, the whole point of this was that I found some code using A, and I figured that B should be faster.
So, I ran the test-- and in mine, B came out way last.
Studying it source code, I found that A just redirects to E, so they were nearly the same.
B, however, uses String's IEnumerable<char> interface to run the Enumerable.Contains<char>() extension method, which is why it was last.
C I tried, mistakenly thinking it would be the same as E. It came out nearly tied with B for last.
D was my overall winner as well.
So, it seems you are experiencing a String.Contains(char) which is specific for strings, which I am not seeing.
I ran the tests on .NET 4.6.1. Are you using .NET Core?
Truth,
James
|
|
|
|
|
Yep, I used .NET Core which may explain the difference.
|
|
|
|
|
Upvoted for 'cheating' being scientific - there's nothing wrong with empirical proof, its exactely what I thought when I saw the question, ie, 'why guess' ..
|
|
|
|
|
Thanks, good way of looking at it I suppose.
|
|
|
|
|
This is the code I ran in release mode. (.NET Core)
class Program
{
const string _str = "abcdefghijklmnopqrstuvwxyz";
static void Main(string[] args)
{
Foo("A", () => _str.Contains("~"));
Foo ("B", () => _str.Contains('~'));
Foo("C", () => _str.IndexOf("~") >= 0);
Foo("D", () => _str.IndexOf('~') >= 0);
Foo("E", () => _str.IndexOf("~", StringComparison.Ordinal) >= 0);
}
static void Foo(string s, Func<bool> action)
{
var sw = new Stopwatch();
sw.Start();
for (int i = 0; i < 1000000; i++)
{
action();
}
sw.Stop();
Console.WriteLine($"{s} - {sw.Elapsed.Milliseconds}");
}
}
|
|
|
|
|
In my experience, the speed measurements at the start of an app are always polluted by the runtime initialization. That is, it might look that "A" takes longer than "B", where actually does not.
Typically, I copy the same piece of code two or three times, then I take the last results.
Have a try, maybe the results will change, maybe not.
|
|
|
|
|
Mario Vernari wrote: Typically, I copy the same piece of code two or three times, then I take the last results. I use sleep 5 seconds, then go for it.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
I'm just an old C++ dinosaur, so my guess is that B and D are the fastest, followed by A and C, and finally the indecipherable twaddle of E--unless it's some kind of secret code for "Hint: you're looking for a single character and therefore don't have to construct "~" , in which case it's probably faster than A and C but slower than B and D.
|
|
|
|
|
Greg Utas wrote: finally the indecipherable twaddle of E--unless it's some kind of secret code for "Hint: you're looking for a single character and therefore don't have to construct "~"
Nope: it's saying "Look for this using a binary comparison, rather than using a culture or shift specific sort order" - basically "compare strings as byte arrays" but using 16 bit values. In theory, this should be much quicker than a non-ordinal comparison as you don't have to deal with "special cases" or "'t' == 'T'", and most processors have machine code instructions for byte based searching and comparing.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Next time I can't decipher some twaddle, I'll know who to turn to.
|
|
|
|
|
|
No, it's ok. Read the sticky on top: The Lounge[^] Point2: Technical discussions are welcome...
|
|
|
|
|
Jorgen is right - this isn't a question seeking help, it's a "Hey! look at this!" discussion.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Also one of the more interesting posts here in recent times.
|
|
|
|
|
Something similar I tried some years ago: Counting Lines in a String[^]
It shows another couple of methods you could have tried.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|