How to analyze 2 programs in Xinlinx ISE5

I made 2 programs(both in VHDL) in 2 different ways on Xilinx ISE5 for Spartan series to do the same thing. Now i want to know which program is more efficient. Efficient in a sense, that which takes less number of gates. How can i find out this efficiency. Plus i also wanna to know that how to programs are analyzed that which program is made in a better way. Though both are working fine.

look at the result of the synthesis. You get information about the critical path and how many resources are needed

View RTL Schematic after synthesis, you can understand more how you design is implemented on FPGA.

If you have done a good constraint file then read the Post PAR result reports you have 4 main reports "if you are not useing mulriple path routing" these reports are the PAR report, Asynchronous delay report, PAD report and PAR static timng report.
the PAR report will give exactly how much did your design took of theFPGA "slice count, PAD, memoriess ... "
the PAD report wil give you information about the Pins assignement locations in the FPGA, volage standard, delay elements if any, IOB flip flops, slew rate ...
Asynchronous delay report will give you a detailed info. about the asynchronous time each net takes until it reach a synchronous element "flip flop, memory" this delay is not related to the clock, this means that this report just tells you how much time it took from x to y
Finally you will have the static time report which will show you the frequency that this PAR has scored and if there is any unmet constraint you will find detailed information about the route of the signal " critical path"
If your PAR can not score the target then try to add some constraints "u can't believe what placement constraints can do"
you can even do a floorplan to your design "I don't prefer that it is a time consuming way, but sometimes you have no other way"

However, all the above is not enough for large designs you can do you own timing analysis if desired, but first you can use the Post PAR model with the standard delay file "SDF" to resimulate the design then if you can't hit the target try doing a more analysis through post PAR timing analysis tool and you may add some constraints over some nets "wires".
if you still can not meet requirements go back to your design "HDL code"
and try to analyze the reason for the delay "usually the reason is not the critical path, i.e. you may make changes on the critical path which introduce another critical path" however sometimes the critical path analysis can solve the prolem.
if the problem presists then you can relax your requirements "if the system can accept"
if the system can no accept such treatment then you have to search for another approach "algorithm" "all what you have done is gone"
Sad but true
However always pipelining will solve any problem "still the pipelining has to be reasonable, i.e there is some point where more pipes can't be tolerated"

thats all folks