I think you've been given a lot of irrelevant information that completely misses the answer you are seeking [sic].

time consumption of perl's seek is related with file size, or it's a constant time operation?

For the purposes of random access, seeking is an amortised, constant time operation, regardless of the size of the file.

That is, all else -- hardware, system buffers, OS, system load, file fragmentation etc. -- being equal, reading the first and then the last records will take the same time as reading the last then then first, regardless of whether the file is a few 10s of megabytes or a few tens of gigabytes.

Is it a costly operation?

It depends upon the amount and distribution of the records you must access. If you were to read the file's entire contents in a random order, it will be significantly slower than reading that same content sequentially.

If however, for any given run or time period, you only need a few records from the entire file, seeking to them and reading just those you need, is much quicker than reading through the entire file to get to them.

Finally, there are various things that can be done to optimise your seek/read times. Primary amongst these is to ensure that your file is contiguous on disk. Second, if at all possible, ensure that records do not span blocks.

It used to be the case -- where the algorithm allowed -- that deferring reads and re-ordering them could reduce head movement and improve throughput, but most disk controllers do this as a matter of course now.

The biggest problem with trying to optimise random access is accounting for the effects of other processes accessing the same file-system and/or hardware.