Support string input in FromData to avoid redundant []byte → string conversion

[aautumn725]

Description
Currently, the FromData(ctx context.Context, verify bool, data []byte) function accepts a []byte parameter, but the data is immediately converted to a string within the function body. However, in most cases, the caller has already converted the input into a string before calling FromData, leading to a redundant and potentially costly conversion cycle (string → []byte → string).

Preferred Solution
Refactor FromData to either accept a string type directly or provide an additional helper method such as FromStringData(...) to avoid unnecessary type conversions.

Example:

FromData(ctx context.Context, verify bool, data string)
This change would help reduce GC pressure and CPU usage in high-throughput scenarios where repeated type conversions could accumulate measurable overhead.

Additional Context
In Go, converting between []byte and string results in memory allocations. For performance-sensitive code paths, especially when processing large volumes of data or in concurrent environments, minimizing these allocations is beneficial.

References
N/A

[shahzadhaider1]

Thank you for taking the time to open this issue, we really appreciate your contribution!

You're right that the string([]byte) conversion is common across all detectors. This is largely because the scanning engine processes raw data from various sources: files, stdin, binary content, etc, which naturally come in as []byte as it's more optimal when scanning large files or repositories in chunks. Maintaining a consistent []byte interface helps simplify integration across 800+ detectors.

That said, you're also correct that unnecessary conversions can add up in high-throughput cases. While the performance impact of string([]byte) is usually negligible compared to more expensive operations like regex matching and API-based verification we do in the detector, your suggestion to support FromStringData(...) could still be worth considering in performance-critical paths.

Tagging @zricethezav for further input/guidance.

[ahrav]

fwiw I did go down this path a while back. 😅 There is some additional color in the comments of the PR.

[kashifkhan0771]

I believe this is somewhat related to issue #1517. The goal is to optimize FromData and allow passing additional information. Overall, this looks like a solid improvement.

I'll try to keep this in mind once we begin working on detectors as config.