19 stories
·
3 followers

My Universal Performance Problem Advice

1 Share

I get asked for recommendations a lot.  Most of the time I have little to no data when asked to perform this sort of divination.  But as it turns out I have this ready-to-go universal advice that works for me, so I'm able to give the same recommendation all the time even with no data!  Handy, huh?

Here it is:

Load as little as you can.  Run as little as you can.  Use as little memory as you can.  Take the fewest dependencies you can.  Create the simplest UI that you can.  And measure it often.  Don’t just measure your one success metric, measure all the consumption and make it as small as you can.  Consider all the important targets, including small devices and large servers.  Nothing else will do, nor is anything else necessary. 

When you understand your costs you will be making solid choices.

Never use non-specific data you think you remember to justify anything.

Last, and most important of all, never take the advice of some smart-ass performance expert like me when you could get a good solid measurement instead.  :)

Read the whole story
Share this story
Delete

Anomalous Propulsion Drive Verified at NASA

1 Share
Here’s a very interesting development that has been brought up here on the Always Open thread, and also discussed on vortex-l. An article on Wired Uk by David Hambling reports how a US scientist named Guido Fetta has built a microwave thruster which works without any propellant and has had a NASA team conduct extensive […]
Read the whole story
Share this story
Delete

Ever have a day like this one?

1 Share
  • Check email and notice a message from somebody having trouble using SQLitePCL.raw on Windows Phone 8.1. Realize that I haven't run the test suite since I started working on the new build scripts. Assume that I broke something.

  • Hook up the automated test project to the output of the new build system. Sure enough, the tests fail.

  • Notice that the error message is different from the one in the user's email.

  • Realize that the user is actually using the old build system, not the new one. Wonder how that could have broken.

  • Bring up the old build system, run the tests. Yep, they fail here too. Must be something in the actual code.

  • Dig around for a while and try to find what changed.

  • Use git to go back to the last commit before I started the new build system stuff. Rebuild all. Run the tests. They pass. Good. Now I just have to diff and figure out which change caused the breakage.

  • git my working directory back to the current version of the code. Rebuild all and run the tests again to watch them fail again. BUT NOW THEY PASS.

  • Wonder if perhaps Visual Studio is less frustrating for people who drink Scotch in the mornings.

  • Decide that maybe something was flaky in my machine. The tests are passing again, so there's no problem.

  • Realize that the user wasn't actually running the test suite. He was trying to reference from his own project. And he had to do that manually, because I haven't published the nuget package yet. Maybe he just screwed up the reference or didn't copy all the necessary pieces.

  • Run the tests in the new build system to watch them pass there as well. But here they STILL FAIL.

  • Decide to take the build system out of the equation and just finish getting things working right with nuget. Build the unit test package separately in its own solution. Add a reference to the nuget package and start working out the issues.

  • Run the tests. Everything throws because the reference got added to the "bait" version of the PCL instead of the to the WP81 platform assembly. Oh well. This is what I need to be fixing anyway.

  • Notice that the .targets file didn't get properly imported into the test project when the package was installed. Wonder why. But that's gotta be why the platform assembly didn't get referenced.

  • Realize that the bait assembly somehow got referenced. Wonder why.

  • What is Scotch anyway? Go read several articles about single malt whiskey.

  • Decide to take nuget out of the equation and focus on why the new build system is producing dlls that won't load.

  • Google the error message "Package failed updates, dependency or conflict validation". I need to know exactly what was the cause of the failure.

  • Realize that the default search engine or IE is Bing. Do the same search in Google. Get different results.

  • Become annoyed when co-worker interrupts me to tell me that there is a new trailer for Guardians of the Galaxy.

  • Read a web page on the Microsoft website which explains how to get the actual details of that error message. Spend time wandering around Event Viewer until I see the right stuff.

  • Realize that the web page is actually talking about WinRT on the desktop, not Windows Phone.

  • Try to find a way to get developer-grade error messages in the Windows Phone emulator. Fail.

  • Notice that below the error message, Visual Studio's suggested resolution is to instead use a unit test project that is targeted for Windows Phone, even thought IT ALREADY IS.

  • Blame Steve Ballmer FOR EVERYTHING.

  • Wonder if WP81 is the only thing that broke. Run the tests for WinRT. They fail as well.

  • Get annoyed because the only way Visual Studio can run the unit tests for just one project is to unload all the others.

  • Get upset because the Visual Studio Reload Project command doesn't work like the way it did a week or two ago. Now it reloads all the projects instead of just the one I wanted. Did the installation of the Xamarin Visual Studio integration break it?

  • Go back to the very basics. Run the unit tests for plain old .NET 4.5. They pass.

  • Re-run the unit tests for WinRT to watch them fail again. NOW THEY PASS.

  • Realize the co-worker is absolutely right. The most important thing is to watch the Guardians of the Galaxy trailer.

  • Get annoyed because the sound on my MBP isn't working. Watch the whole trailer anyway, without sound.

  • Review all my project settings in the Visual Studio dialogs, just to see if I notice anything odd.

  • Go back to my web browser. Realize that the world of Scotch whiskey might actually be more complicated than Visual Studio.

  • Go home. Discover that the annual spring invasion of ants in our kitchen is proceeding nicely.

  • Fight some more with Visual Studio. Give up. Go to bed.

  • Wake up the next morning. Discover that the teenager's contribution to our war against the ants was to leave unrinsed plates by the sink. Thousands of ants feasting on cheesecake debris and syrup.

  • Open the laptop. Run diff to compare the csproj and vcxproj files from the old build system against the new one. See that there are no differences that should make any difference.

  • Change them all anyway. Update every setting to exactly match the old build system. One at a time. Run the test suite after each tweak so I can figure out exactly which of the seeminlgy-harmless changes caused the breakage.

  • Wait. My kid had cheesecake and waffles FOR DINNER?

  • Become seriously annoyed that Visual Studio changes the Output pane from "Tests" to "Build" EVERY SINGLE TIME I run the tests.

  • Finish getting all the settings to match. The tests still don't pass.

  • Try to remember if I ever done anything successfully. Anything at all. Distinctly recall that when I was mowing the lawn this weekend, the grass got shorter. Focus on that accomplishment. Build on that success.

  • Realize that the old build system works and the new one doesn't. There has to be a difference that I'm missing. I just have to find it.

  • Go back to the old build system. Rebuild all. Run the tests so I can watch them pass and start over from there. BUT NOW THEY'RE FAILING AGAIN.

  • Go do something else.

 

Read the whole story
Share this story
Delete

Introducing dotPeek 1.2 Early Access Program

1 Comment

It has been a while since dotPeek, our free .NET decompiler, received its latest update, but that doesn’t mean we put it aside. Today we’re ready to launch the dotPeek 1.2 Early Access Program that introduces a substantial set of new features.

Starting from version 1.2 dotPeek learns to perform as a symbol server and supply Visual Studio debugger with the information required to debug assembly code. This can be most useful when debugging a project that references an assembly from an external class library.

dotPeek listens for requests from Visual Studio debugger, generates PDB files and source files for the requested assemblies on demand, and returns them back to the debugger. dotPeek provides several options to choose exactly which assemblies you want it to generate symbol files for.

Symbol server options in dotPeek 1.2 EAP

To learn more on how to set up dotPeek as a symbol server and use it for debugging in Visual Studio, please refer to this guide.

In case that the Visual Studio cache already contains PDB files for certain assemblies but you would like to replace them with PDB files generated by dotPeek, use the option to generate PDB files manually. In order to do that, simply select an assembly in dotPeek’s Assembly Explorer, right-click it and choose Generate PDB.

Generate pdb in dotPeek 1.2

dotPeek can export to project and generate PDB files in the background, meaning that you can explore assemblies during PDB generation or assembly export. To address cases when it’s not clear whether PDB files were generated properly, dotPeek has a dedicated tool window that shows current status and results of PDB generation.

PDB generation status in dotPeek 1.2 EAP

In addition to the set of features that streamline debugging decompiled code, dotPeek 1.2 adds quick search and node filtering in various trees, most notably Assembly Explorer. Searching and filtering using lowerCamelHumps is supported for these scenarios.

Search in Assembly Explorer in dotPeek 1.2 EAP

If you’re interested to learn about other fixes and improvements made for dotPeek 1.2 EAP, this link should help you out.

Does the above sound enticing? Download dotPeek 1.2 EAP and give it a try!

Read the whole story
Share this story
Delete
1 public comment
marklam
1343 days ago
reply
Damn! In your face, Redgate :-)
Gateshead/Newcastle UK

The .NET Foundation and .NET Platform Innovation

2 Shares

.NET has been a bedrock of the Microsoft developer ecosystem ever since its initial release more than 12 years ago.  The over 6 million professional developers using .NET have built some of the most important software and solutions powering businesses, apps and sites today, and the 1.8 billion installs of.NET across devices have created a key foundation for productive application development.

Today, I am thrilled to share with you some important updates on the .NET platform, including a wide array of important innovations around .NET as well as the creation of the .NET Foundation to foster further innovation across the .NET ecosystem.

The .NET Foundation

Earlier today we announced the formation of the .NET Foundation, an independent organization created to foster open development and collaboration around the growing collection of open source technologies for .NET.  The .NET Foundation will serve as a forum for commercial and community developers alike with a set of practices and processes that strengthen the future .NET ecosystem.

As I highlighted recently, we have seen a significant increase in the amount of open source software that makes up the foundation of the .NET development ecosystem, both from Microsoft and from other developers in the .NET community.  The .NET Foundation builds upon this trend, and further helps the open ecosystem for .NET to flourish.

The .NET Foundation will start with 24 .NET open source projects under its stewardship, including the .NET Compiler Platform (“Roslyn”) and the ASP.NET family of open source projects, as well as the MimeKit and Mailkit libraries from Xamarin.

Our shared goals for the .NET Foundation are:

  • Open the development process for .NET: The .NET Foundation brings under a common umbrella existing and new relevant open source projects for the .NET platform, such as ASP.NET, Entity Framework and the recently released .NET Compiler Platform (“Roslyn”). The .NET Foundation will help establish this as the norm moving forward, so more and more .NET components and libraries can benefit from an open process that is transparent and welcomes participation.
  • Encourage customers, partners and the broader community to participate: The .NET Foundation will foster the involvement and direct code contributions from the community, both through its board members as well as directly from individual developers, through an open and transparent governance model that strengthens the future of .NET.
  • Promote innovation by a vibrant partner ecosystem and open source community: The .NET Foundation will encourage commercial partners and open source developers to build solutions that leverage the platform openness to provide additional innovation to .NET developers. This includes extending .NET to other platforms, extending Visual Studio to create new experiences, providing additional tools and extending the framework and libraries with new capabilities.

The .NET Foundation represents a key commitment to the open .NET ecosystem, and I look forward to what we will be able to deliver together via the Foundation.

.NET Innovation

Over the last 12 years, the .NET platform has delivered dozens of major innovations across the runtime, language, libraries and tools.  From projects like Language Integrated Query to the rich ASP.NET framework and more recently the Async/Await features for asynchronous programming, .NET has been a leading platform for productive application development in the industry.

Today, we had a chance to unveil the next batch of exciting innovations in the .NET platform, running the gamut from core runtime features to enabling new developer productivity tooling.  Together, this wave of .NET innovation represents an important next step for the .NET platform.

The .NET Compiler Platform - "Roslyn" (preview)

The .NET Compiler Platform project, known as "Roslyn", includes the next versions of the C# and VB compilers, as well as a compiler-as-a-service API that powers rich IDE integration, and opens up the compiler to all sorts of developer integrations. 

Today, the .NET Compiler Platform was released as open source by Microsoft Open Technologies, with the development team now working on CodePlex.  The open source compiler platform will enable a broader community of developers to contribute to the evolution of the project and to integrate the .NET compilers into a wide variety of projects.

The .NET Compiler Platform preview release also includes several new IDE features, highlighting what’s possible on top of the new platform.

It's not just Visual Studio that benefits from the open source .NET compiler platform.  Today at //build/, Miguel de Icaza of Xamarin showed how the .NET Compiler Platform can be used to provide a rich C# IntelliSense experience in Xamarin Studio running on a MacBook.

Open sourcing the .NET Compiler Platform and the C# and VB compilers opens up countless new opportunities for tools and services to be built around .NET.

C# and VB language Innovation (preview)

The preview versions of the C# and VB compilers included with today's .NET Compile Platform include an early look at some of the new features being considered for the next major version of the C# and VB languages.  Features like primary constructors, auto-property initializers and using statics generally help developers express common code patterns in an even more streamlined way.

// Using static class
using System.Console;
 
// Primary constructor
class Point(double x, double y)
{
    // Auto-property initializers and getter-only auto-properties
    public double X { get; } = x;
    public double Y { get; } = y;
    public void PrintMe()
    {
        WriteLine("{0}, {1}", X, Y);
    }
} 

.NET Native (preview)

The developer productivity of C# and .NET has been a core value proposition for the .NET platform.  With .NET Native, we are marrying that productivity with the ability to generate binaries with performance on par with native code. 

.NET Native is an ahead-of-time compiler for .NET which leverages our C++ compiler's optimizer to offer improvements to startup time, memory usage and overall application performance.  Today's preview release lets developers try out this new compilation technology for Windows Store applications targeting X64 and ARM. 

Read more about .NET Native on the .NET blog.

Next-gen JIT and SIMD (preview)

At the core of .NET, we have been working on a next-generation JIT for .NET and the CLR.   Today, we released the third preview release of this new .NET JIT compiler (codename "RyuJIT"), offering significant benefits to application startup and performance transparently to application developers.

Today’s preview is the first to also enable new developer scenarios, such as providing new .NET APIs that can leverage the SIMD (Single Instruction, Multiple Data) support in modern processors for SSE2 and AVX instruction sets.  In this example, floating point arithmetic in a tight loop is vectorized, significantly increasing overall throughput.

Vector<float> reals = vx;
Vector<float> imags = vy;

do
{
   // This work will be vectorized using hardware SIMD instructions
   reals = reals * reals - imags * imags + vx;
   imags = reals * imags + reals * imags + vy;
 
   // … do more work …
 
} while (!done);

The SIMD APIs are available on NuGet.

Xamarin Partnership

Last November, we announced a partnership with Xamarin to enable C# and Visual Studio developers to target additional mobile devices including iOS and Android. 

By using .NET Portable Class Libraries, developers can easily share libraries as well as application logic across their device applications as well as with their backend implementations. 

Visual Studio and .NET offer outstanding developer productivity for application developers targeting the Windows family of devices.  With Xamarin, developers can take this productivity to iOS and Android as well.

.NET Mobile Services

Azure Mobile Services provides an easy-to-use mobile backend as a service connected to Microsoft Azure.  Last month, Scott Guthrie announced the preview availability of .NET support for Mobile Services, and today, we've taken this another step forward.

With .NET mobile services, you get the simple API connection to Azure-hosted data storage, combined with the flexible ASP.NET Web API for customizing table behavior.

Project "Orleans" (preview)

Based on work started in Microsoft Research, "Orleans" is an actor-based cloud programming model, offering a straightforward approach to building distributed high-scale computing applications, without the need to learn and apply complex concurrency or other scaling patterns. Orleans was designed for use in the cloud, and has been used extensively in Microsoft Azure. 

Read more about Orleans on the .NET Blog.

Conclusion

.NET is one of the world's leading developer platforms, and a critical technology for Microsoft and millions of developers worldwide.  The .NET Foundation will foster open development and collaboration around the growing collection of open source technologies for .NET, supported by Microsoft and other organizations investing in the .NET platform.  The next wave of .NET innovation being previewed today represents a huge step in the evolution of the .NET platform.

And this is just the beginning, the pipeline of innovation in .NET is in full gear leading up to the next version of .NET, with features to help you create the next generation of applications across Windows Server and Azure, as well as the desktop and devices.

Namaste!

Read the whole story
Wilka
1343 days ago
reply
Newcastle, United Kingdom
Share this story
Delete

Buggy milk cartons, beeping computers, and other silliness

1 Comment

Some time ago, there was a performance-related bug that went something like this:

mm/dd/yy Created by bob
The attached file contains a dataset that takes a very long time to process.

The engineer who fixed the problem decided to take the cryptic approach:

mm/dd/yy Resolved as fixed by alice
It got better.

It was a common practice during highly stressful periods to file humorous bugs in the defect tracking system, and once the initial bug was filed, it turned into a sort of collaborative performance effort.

For some reason, milk is often a trigger.

Many years ago, the vendor who supplies milk to Microsoft changed the design of their milk cartons, and the new cartons were significantly harder to open than the old cartons. (Apparently they bought a new machine, and the glue level needed to be tuned.) This naturally inspired people to do what they usually do when they see something amiss: File a bug.

More than one person was inspired to file a milk carton bug, but probably the most famous one is the one reprinted by Korby Parnell back in 2003.

Kraig Brockschmidt describes an earlier milk carton bug:

A friend of mine who worked as a tester on Microsoft Excel once logged a bug against the cartons of milk in the free drink coolers. He noticed that the chocolate milk failed to list the ingredient "cocoa" whereas the plain 2% milk did. An intense discussion in raid [the defect tracking system] over the relative merits of these "features" continued for three or four weeks and involved as many as a fifteen different engineers. I think it set some kind of record. Anyway, someone finally went so far as to notify the dairy itself and the bug was closed as "won't fix—assigned to vendor."

(In the years since the original story occurred, our defect tracking system gained a new resolution class, and today it would be resolved as "external—assigned to vendor.")

Over in the languages group, there was a bug that went roughly "IDE fails to beep when build is finished." Nobody can find a copy of the bug any more, it having been archived away ages ago, but one of my colleagues recalls that it went something like this:

  • Start a build.
  • Leave office to get a beverage from the kitchen.
  • Return to office.
  • Observe that build has finished, but no beep was heard.

One person resolved the bug "Not Repro" because they stood just outside the office and clearly heard the beep, but that led to a debate over how far from the office you needed to be in order to reproduce the bug. Things got sillier and sillier until someone finally closed the bug after claiming to have taken their computer out to the forest behind the building and started the compilation. When they returned 30 minutes later, they found that a tree had fallen on the machine.

I admire the philosophical resolution to that one.

Read the whole story
Share this story
Delete
1 public comment
marklam
1351 days ago
reply
I was involved with this! I feel almost famous :-)
Gateshead/Newcastle UK
Next Page of Stories