Electronic – In VHDL, does having large bus input to component take extra resources

I assume that you mean that you have a combinational (not asynchronous) logic which represents critical timing path which limits the frequency, right?

Your Static Timing Analysis (STA) tool have no idea that you allow this component to spend several clock cycles before you expect to get a valid output. Synthesis still thinks that the propagation from the input stage to the output stage should take place in a single clock cycle. It makes its best to optimize this path, but still, the propagation delay is too long.

You have several options:

1. The best option in such cases is to split the combinational path into few smaller path, and add register for sampling the intermediate results of the reduced paths. This will reduce the propagation delays, but will add latency - you will get the valid output delayed by the number of sampling stages.
2. If you do not want to mess with this logic (it is too complex, or it is "silicon proven", or any other reason), you can do what you did: add sampling stages before and after the logic, and add additional control logic which knows how many cycles to wait for the valid data (and not allow the inputs to change). However, you must communicate such an unusual intent to all the tools. Information like this was given a general name: "design constraints". Now, I don't know how to specify design constraints for your FPGA (I think it will not take you more than 10 minutes to understand how). What constraint do you need to add? These kind of combinational paths which take more than one cycle are called "multi-cyle-paths" (MCPs). Find it in the documentation of your FPGA\IDE.

NOTE: there is yet another design constraint which may help you - "false path" (FP). When you define some path as FP, no tool will try to derive any timing for this path. This is useful for DFT stuff, clock muxes etc. However, even you may be tempted to use it in this case (FPs are much more simple to define properly than MCPs), don't do it! MCPs constraints must be validated by formal tools, therefore if you define MCP as FP you are masking many potential bugs.

The short form answer : first delete the non-standard library ieee.std_logic_arith.all;

It and its std_logic_[un]signed cousins are a mess of slightly ambiguous functions that obscure what your code means and can fail unexpectedly like this example. Does conv_std_logic_vector generate a signed or unsigned representation? Does that depend which libraries you are using? Does conv_integer convert TO an integer, or FROM an integer?

Second, decide what your std_logic_vector quantities represent : signed or unsigned numbers?
You can declare them as signed or unsigned instead (from ieee.numeric_std library). If you MUST keep them as std_logic_vector (WHY?) then you can cast between types via signed(), unsigned(), std_logic_vector().

Then you can replace

A <= conv_std_logic_vector(va, A'length);
vr := conv_integer(R);

with

A <= to_unsigned(va, A'length);     -- or to_signed
vr := to_integer(R);