Visual Studio crashes while developing WPF XAML. Out of memory, taking too much memory to process

Introduction

You may have experienced an annoying behavior of visual studio while developing WPF XAML. Say for example Visual Studio consumes large amounts of memory and shows Not Responding message on a regular basis while designing XAML This is because of the XAML designer (Microsoft Visual Studio XAML UI Designer) which visual studio loads while editing XAML. There will be one for each XAML that you open for editing.

How did I fix it:

While developing XAML, we rarely looks at the designer and we tend to rely on our expertise in writing XAML. If you are also the one who don’t rely on XAML designer, then you can ask visual studio to not to load designer and thereby saving a lot of memory thereby avoid visual studio crash because of out of memory. Below described are the steps which you have to follow to avoid loading XAML designer.

  1. In visual studio, go to Tools –> Options menu,
  2. Open the Text Editor node, then the XAML node,
  3. Then select the Miscellaneous node; make sure that under the Default View heading there is a checkbox beside Always open documents in full XAML view.
  4. Go to solution explorer -> Right click on any .xaml and say open with. Now select Source Code (Text) Editor and set it as default.

Restart visual studio and enjoy a new development experience. Here if you look at the task manager, you still can see one xaml designer running (Microsoft Visual Studio XAML UI Designer). This is required by visual studio for compilation purpose so just ignore it.

Parquet file experiments, findings and recommendations

Parquet is a binary file format designed with big data in mind where we must access data frequently and efficiently. The way it stores file on the disk is also different from other file formats. It is a column-based data file. And in reality it uses both row based and column based approach to bring the best of both worlds. The data is encoded on disk which ensures that the size remains small compared to actual data and is then compressed where the file is scanned as whole and cut out redundant parts. The query/read speed is dramatically fast when compared to other file formats. Nested data is handled efficiently which is quite cumbersome in other file format to achieve. Doesn’t require to parse the entire file to find data due to its way of storing data. This makes it efficient in reading data. Works quite efficiently with data processing frameworks. Automatically stores schema information. SQL querying is possible with this file format using Continue reading

Libish Varghese Jacob

Libish Varghese JacobI am currently working as a lead engineer in one of the leading wind turbine manufacturing firm. I have wide range of interests and getting my hands dirty in technology is one among them. I use this platform primarily as my knowledge base. I also use this platform to share my experience and experiments so that it might help someone who is walking the way I already did. The suggestions expressed here are the best to my knowledge at the time of writing and this may not necessarily be the best possible solution. I would pretty much appreciate if you could comment on it to bring into my notice on what could have been done better.