Optimizing the Code ... Optimizing the Solution

Sometimes developers are over excited about creating an optimized solution by optimizing & refactoring the code. They try to optimize every bit and line to their heart's content. Optimization is an art, but sometimes you gotta admit that overdoing any art, loses it's beauty. So, what optimization process should be followed? Well, I want to share my view on that matter.

Create a solution but don't bother about the "Perfect solution" 

          What good a highly optimized, well written & well maintained code base can do, when it can not solve the problem? The simple answer is nothing. Every solution is written so that it could solve a problem. If you are given a non working but nicely written application will you choose it over a badly coded working solution? I guess, you got the point.

Optimize the solution but never over do it 

          Then next state would be optimize the solution. After you have a solution you can make it more better. Break the function into small functions. Group the class into a module. Apply DP where appropriate.

The 90 - 10 rule

          Try to optimize the section which consumes most of the time. The 90 - 10 rule follows as -  10% of code constitutes 90% of total running time of the application. Have you ever think of any solution not having a loop? Have you seen a complex algorithm not having several loops? These loops are the CPU cycle hogger. They are the 10% out of 100% code. Try to optimize that 10% before optimizing other sections. Slight improvement over that 10% will leave a mark on the performance of your application.

Thank you for reading.

DateTime Picker in JDK 7

JDK 7 is in draft stage. The feature list of JDK 7 is great. Existing Java developer will instantly notice the feature list as a blessing :D .

Today I am going to show a JDK 7 SwingX Component, JXDatePicker. As JDK 7 is still in draft phase, You cannot get official JDK7 release. Instead you can download JDK7 Snapshot from this Link.
Now once you have got the JDK7 release you can test out the DatePicker.

JXDatePicker dtPicker = new JXDatePicker(System.currentTimeMillis());
dtPicker.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent e) {
          JOptionPane.showMessageDialog(null, datePicker.getDate().toString());
    }
});

Let the JDK prevail ...

SpeedUp Windows Kernel Debugging - VirtualKD + VMPlayer + WinDbg

Traditional windows kernel debugging requires two PC ( host & target ) to be connected via serial null modem. As this connection is an emulated modem, the debugging speed is very low. Also you need two PC in order to perform debugging.

VirtualKD & VMPlayer together now made it possible to speedup debugging in same PC !!!

Steps to the speedup debugging -

1. Install VMPlayer.

2. Install the target system (which you want to use for debugging) in the VMPlayer.

3. Run the guest OS (target system) in VMPlayer.

4. Install VirtualKD in guest OS

5. Make sure you have selected "Make new boot entry" while installing the VirtualKD

6. Now your guest OS be restarted. Open the vmmon.exe or vmmon64.exe (based on your OS) in the host (original PC). This application will try to patch the VMPlayer to make the debugging possible on the VMPlayer.

7. Set up the debugger path in the vmmon.

8. Now run the guest OS and select the entry which has "[debugger enabled]" prefix entry.

9. Running the guestOS will bring up the Debugger and it will try to connect with the ruuning os.

10. The debugger will automatically connect with the VirtualKD driver and execution of the windows kernel will be in break mode. Enter g (go) to resume the loading of the windows.

11. to stop execution of the windows kernel press Ctrl+Break in the WinDBG. This will stop the kernel execution and let you to enter command to the WinDbg like step, dataview , setting breakpoint etc.

12. To enable debugging we need to first setup the symbol file (.pdb). You can set the symbol path from "File" menu. Or you can enter the command .sympath+ <symbolpath> to extend symbol search path.

13. Next step is to set the source file search path. This is needed to debug line by line (step or p). 

That's it. Your high speed debugging environment is setup perfectly. Now if you load a program & set breakpoint, the debugger will automatically break execution on that point. If the correct symbols are shown to the debugger with the correct source code, you will be able to see which line is executing from the WinDBG (just like VS debugging).

To speed up more, you need to learn basic WinDBG commands.

Hope this article will help you. If you have any question or suggestion, please leave a comment.