First I guess this will open every file and close it before opening the second file to search for the word? is this efficient, if not is there a way more efficient?
Yes, grep will open and search every file in turn. On most setups, that's the most efficient way. Unless the regexp is extremely complex, this task is firmly I/O-bound, i.e. the performance bottleneck is reading from the disk, and your CPU will not be taxed.
On some setups, I/O can be parallelized; for example, if you have a RAID-1 or RAID-0 configuration, then the two (or more) components in the RAID array can be read from in parallel, which will save time. If you have such a setup, you can call a tool like GNU Parallel to call two instances of grep (see the manual for command examples). On most setups, calling two instances of grep in parallel will be slower, because the disk heads will keep switching between the files accessed by the two instances (with SSD, calling two instances in parallel will typically not cause a major slowdown, but it won't be faster either).
If you pass more than one file on the command line, grep outputs the file name before each match, in the format
path/to/file:line containing a match
If you're using a wildcard pattern or some other forms of generating file names and you want to display the file name even in the case when there happens to be a single matching file, tell grep to search the empty null device as well.
grep REGEX /dev/null *.txt
grep -H REGEX *.txt is similar, but using
/dev/null has the additional benefit that it works seamlessly even if the list of matching files is empty, whereas
grep -H REGEX reads from standard input.)