You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed that callstack information extraction is based on the use of a regular expression
It seems to work fine, but I wonder if the process could gain some speed-up by avoiding going thru all the burden of extracting it from call stack layers formatted as strings.
Indeed those strings themself got those informations from a NodeJS internal data structure !
And, fortunately, in the latest versions of the V8 engine, it's possible to skip the whole string & regexp management part using this feature
Here is a code sample I've already successfully used on a project :
constNOT_AVAILABLE_STRING="N/A"functiongetStackInfo(){// see following links for further informations about how to get the informations back :// - https://v8.dev/docs/stack-trace-api// - https://stackoverflow.com/questions/11386492/accessing-line-number-in-v8-javascript-chrome-node-js// - https://stackoverflow.com/a/59706213constoldStackTrace=Error.prepareStackTrace;try{// eslint-disable-next-line handle-callback-errError.prepareStackTrace=(_,structuredStackTrace)=>structuredStackTrace;conststackInfoAccessObject=newError();Error.captureStackTrace(stackInfoAccessObject);// we have to peel the first callstack layers in order to get to the actual caller of the logger function// otherwise we'll always get the same callsite, pointing constantly to this logger.js file ... which would be useless :)// // To do so, let's skip layers up to the current file reference (included)// And because there could be several layers pointing to this file, let's perform a bottom up search :constreversedStackShallowCopy=[ ...stackInfoAccessObject.stack].reverse()// now we're reverted the callstack, we can look for the first occurence of current file name :constpreCallsiteIdx=reversedStackShallowCopy.findIndex(stackLayer=>stackLayer.getFileName()===__filename)// once found, what we're looking for is the callee of this layer, so the previous one :constcallSite=reversedStackShallowCopy[preCallsiteIdx-1]// and to simplify the filename path, only keep the part relative to the project base directory :constrelativeFileName=path.relative(PROJECT_BASE_DIRECTORY,callSite.getFileName())// now we can return the requested informations :return{column: callSite.getColumnNumber(),line: callSite.getLineNumber(),func: callSite.getFunctionName(),method: callSite.getMethodName(),file: relativeFileName,};}catch(err){return{// in case of errors, return a placeholder structure ...column: -1,line: -1,func: NOT_AVAILABLE_STRING,method: NOT_AVAILABLE_STRING,file: NOT_AVAILABLE_STRING,}}finally{Error.prepareStackTrace=oldStackTrace;}}
Of course, this sample is missing some features of already working version of defaultParseCallStack but it should be difficult to add them I guess
Please, notice that I can't certify that it will run faster, because I didn't performed tests myself.
But I doubt it could run slower, and the whole point here is to produce a code that should be stable.
Using an extraction process based on the v8 data structure prevent the code from having to change along potential futur changes of the call stack's string formatting process
The text was updated successfully, but these errors were encountered:
Mumeii
changed the title
Extract callstack informations thanks modern feature
Extract call stack's information thanks latest v8 features
Nov 11, 2022
Hi
I've noticed that callstack information extraction is based on the use of a regular expression
It seems to work fine, but I wonder if the process could gain some speed-up by avoiding going thru all the burden of extracting it from call stack layers formatted as strings.
Indeed those strings themself got those informations from a NodeJS internal data structure !
And, fortunately, in the latest versions of the V8 engine, it's possible to skip the whole string & regexp management part using this feature
Here is a code sample I've already successfully used on a project :
Of course, this sample is missing some features of already working version of
defaultParseCallStack
but it should be difficult to add them I guessPlease, notice that I can't certify that it will run faster, because I didn't performed tests myself.
But I doubt it could run slower, and the whole point here is to produce a code that should be stable.
Using an extraction process based on the v8 data structure prevent the code from having to change along potential futur changes of the call stack's string formatting process
The text was updated successfully, but these errors were encountered: