Execution time in bcrypt does not depend on the input size; internally, the input string is padded into a fixed-length sequence of bytes, and that sequence is then used throughout the algorithm.
It would be a problem if execution time depended on input size, because the "cost factor" parameter is adjusted to make the execution time as high as is tolerable. The question is relevant, but, fortunately, bcrypt does not have this specific weakness.
Note: input passwords for bcrypt have a maximum size of a few dozen bytes. There are ways around it which involves a pre-hashing step (that step would take a time proportional to the password size, but it would be muuuuuch faster so the time overhead would be negligible, unless you are in the habit of typing passwords of several megabytes, which is impressive but weird).