I read this somewhere a few months back. While you are working on your Windows Desktop it helps a lot if you keep your Windows (applications) minimized to the task bar. The deal is that as soon as you minimize down a window the application's memory usage goes down. So by minimizing all the applications and having only the application you are working active gives you more free RAM.

As I write this article I have a 20 page word document, which shows a 14.4MB of Mem Usage. When I minimize it, the usage goes down to 2.2 MB.

So if you are the kind of people who are used to opening too many windows, you would be better utilizing your computer if you keep all your non-active windows minimized.

Click [Windows]+D now.

I use Photoshop CS2 a lot, which has a huge requirement on memory. If I load a PSD file, CS2's mem usage goes to 211MB. The memory usage does not come down even if you close the PSD file, but in fact in my case, it went up to 212.5MB.

Open another PSD and it shoots up to 216MB. It will continue increasing as you open and work on more images. Even if you close all files in CS2, the mem usage will still hang there. After a while you will find your PC's mem usage unbelievably high and CS2 behaving very slow. It may take a few minutes now to crop a picture. If you minimize your CS2 window, then the mem usage will dive down to 3MB. Maximize it and its just 10MB. Its a heavenly experience to see your app's mem usage come down from 300+Mb to 10MB.

Initially I used to blame the CS2 developers for having such huge memory leaks in their app, but now I realize that this is a Windows thingy! Its a good idea to minimize and maximize your CS2 often.

One of the many qualities of Production Quality Code is to be able to handle all possible errors gracefully and recovering if possible. Even if these error have a one in a million chance of happening, a good production quality code requires programmers to handle the errors.

Error handling code either take the form of a big if-then-else statement or a more graceful exception handling mechanism. Error handling happens when a certain operation fails to perform as expected. For every such operation there are generally many failure reasons. These failure reasons are handled in the else part or the catch block. It may turn out that in the process of handling all error conditions or exceptions, a lot of code has been written and the size of these error handling routines is substantial.

I have wondered many times : "How much of such error handling code and variables are loaded on my RAM ?" The probability of these code+data being used is very rare. They are just sitting on my RAM doing nothing? With 50+ processes running on my home PC, how much of my 1GB RAM is dedicated to holding memory for these error/exception handling routines? But you cannot ignore these code, as you want to handle a bad condition gracefully.

What is needed is a processor architecture that allows programmers to specify via a high level languages these low probability code segments. I am not talking of the likely and the unlikely macros which use the processor's branch prediction capability. They help improve performance but not by saving RAM.

The architecture should not load those less-probable code into memory unless the error or the exception condition is met. While working for Nortel Networks in the beginning of my career, I had come across a similar architecture and there was a possibility in the language (Protel, their in-house proprietary programming language) to do precisely that. I don't remember much now.

I believe that it wont be easy to implement such a thing, but it would be a very much welcome thing, given the fact that almost all computer users today crib about their RAM usage more than the HDD or the CPU.

Thoughts?

After 2 days of struggling with Intel VTune on my Linux VMWare workstation and after trying several versions of VTune, I learned the hard way that you cannot get the Sampling data from VTune if you are running it on VMware.

I wish VTune would give me a better error message then just saying "Failed to create sampling data base. Probably .tb5 files are corrupted or don't exist." and "The Sampling Collector failed to collect data because the selected event(s) did not occur."

Looking at other people who were facing the same problem, the common suggestions were to try a different version of VTune. Yeah, thats where I wasted my time -- the error on .tb5 files was a bit misleading.

Thanks to Intel Forum post, I found and confirmed that Intel VTune is not supported on VMware. Here is another explanation from Intel on this. Having read these, it is understandable why VTune is not supported on any Virtual system. With Virtulization technology becoming so popular among developers, I wish Intel can do a bit more to let know that it is not supported.

The only good news is that you can still generate call graphs using VTune on VMware, but thats not the reason why you want to use VTune.

Today discussion is around programming in C/C++ and file IO.

Almost all programs require reading files from disk to perform their duties. I have been using fread(), read() or C++'s fstream classes to perform the file IO. The way these file IO works is : Data is copied from the disk to a kernel buffer, then the kernel buffer is copied into the process's heap space for use. The data as you see is copied twice. These file IO is always buffered and the amount of buffering differs from one OS's implementation to another.

This works good for small files, files which programs read for configuration details and writing log files, etc.

But what about large data file? A file which is in the order of a few MBs can choke the system. In most cases (maybe except for photo editors, or video programs) it is generally not required to get the entire data for a particular operation. We sometimes need to access random parts of a large file at random times.

Try to solve this problem with the tradition fread/fseek calls and you will end up wasting too much CPU and memory.

The concept of memory mapping of file allows the program to copy the data from the disk straight to the process space. This allows the program to view the contents of the file as an array -- you get the pointer to the first byte of the file. This translates to better usage of CPU and RAM.

In UNIX these can be accomplished by the mmap() function and in Windows its the MapViewOfFile() function. Using these functions is not as easy as using the traditional reads as the programmer may need to take care of certain things:
1. You may need to map only a particular section of the huge file into memory and need to do the alignment with system pagesize.
2. Delicate pointer handling and proper usage of read write permissions.
3. Make sure you dont map a very huge file into your process space, which can lead to too many page faults.
4. Never write pointers into these files. Keep only offsets if you need.

It also allows you to dump serialized objects which you can directly load into memory and cast it to the required type and start working right away.

This technique is only suitable for certain cases and the programmer must make sure that he/she gets measurable advantage using memory mapped files.

Suggested Reading:
1.Sun Developer Network : A Performance Comparison of "read" and "mmap"
2.Pros and Cons of Memory mapped file and when not to use memory mapping.
3. Memory Mapped Files And Shared Memory For C++.

All Unix users are aware of the DAC (-rwxrwxrwx) that we always use to prevent others from accessing files we don't want them to. But there are times when you want more than that.

You may say:
1. I want to prevent myself from accidentally deleting a file despite having -rwxrwxrwx permissions.

2. If you have 000 permissions for a file, then you cant delete it without changing the permissions first. But you can straight away do a "rm -f" .Many people are just used to using the "f" flag(I sometimes wonder if the "f" flag meant "force" or something else). If you are a Linux sys-admin and you are sharing the root password with fellow admins, then you definitely need something to warn your fellow-admins from doing something wrong accidentally. The traditional DAC does not allow you to this. For DAC "root" is as good as God.

3. I want to prevent every body (including root) from deleting the file or writing to file, BUT YOU WANT TO ALLOW THEM TO ADD DATA TO FILE. ie, allow only appending.

A very less know Linux command "chattr" allows you to do precisely these by making the file immutable. This works only for EXT2/ETX3 file-sytems only. If you set the immutable attribute for a file, it means that it cannot be modified, deleted, renamed and no hard links can be created to this file.

Even a root user attempting to delete this file with get the message "Operation not permitted". Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

chattr +i <filename> sets the immutable attribute of the file.
chattr -i <filename> clears it.
lasttr <filename> will show the status of the attributes.

This not-so-popular command has got a bunch of other attributes that you can set either to improve the security of your system or even to increase performance.

Using the +a attribute you can make the file to be opened only in append mode. (-a to remove the attribute.

For a security sensitive file-system you may want to set the "+s" attribute which will make sure that when you delete the file, the contents in the hard disk are all zeroed out.

Read the man pages of lsattr and chattr for more details and limitations/bugs. The full features of chattr are not yet available.