I'd go instead with https://www.simple-talk.com/sql/performance/finding-the-causes-of-poor-performance-in-sql-server,-part-1/

Eirikur's query will show individual queries with high CPU usage, but by using just that you may miss the queries which are running very, very frequently.

Which is worse for overall CPU usage, the query that uses 30 seconds of CPU and runs twice an hour, or the query which uses 600ms of CPU and runs 5 times a second? If you look only at individual queries, you'll identify the first, probably not the second.

Oh, and a minor correction

SELECT TOP (10)

*

FROM sys.dm_exec_requests DER

INNER JOIN sys.dm_exec_sessions DES

OUTER APPLY sys.dm_exec_sql_text(DER.sql_handle) DEST

WHERE DER.status = N'running'

AND DER.session_id = DES.session_id

AND DER.session_id <> @@SPID

ORDER BY DER.cpu_time

It shouldn't be an apply between exec_requests and exec_sessions. Apply is used to run a function or subquery once per row of the outer query, it's not a replacement for a join and, if used as one, generally runs really slow. Not a problem here, these DMVs shouldn't have lots of rows in, but can be a problem when used with large tables. I've seen a query go from 13 hours to 20 minutes by replacing an unrequired APPLY with a JOIN.