CODEWITHSUNDEEP
tcl
Himanshu Gupta
Himanshu Gupta

Reputation: 11

How much memory does Tcl_Obj* consumed , do i need to delete it?

std::string cmd = get_itcl_obj_name() + " set_ude_jobname " + name;
Tcl_Obj* cmdobj = Tcl_NewStringObj(cmd.c_str(),-1 );
if(Tcl_EvalObjEx(interp, cmdobj, TCL_EVAL_GLOBAL) == TCL_OK)
{
    return true;
}
else
{
    return false;
}

I have this part of code which is called thousands of time and consuming high memory, so i am not able to decide if this tcl object pointer needs to be deleted?

Upvotes: 1

Views: 203

Answers (1)

Donal Fellows
Donal Fellows

Reputation: 137637

A Tcl_Obj points to a piece of memory that is 24 bytes long on a 32-bit system (I've not measured on 64-bit systems, but it could be up to 48 bytes, depending on how the compiler packs the structure). It can also point to further memory that can be variable in size; gigabytes is most certainly possible on 64-bit systems. In particular, the string representation of the value can be hanging off it, as can other things like list or dictionary representations. (The details are very variable under the covers.)

So yes, they should be released properly once no longer needed! While you never need to do that at the Tcl language level (other than by using unset on global variables occasionally) it's vital that you get the reference count management correct at the Tcl C API level.

In the specific case of the code you're working with, you need to both Tcl_IncrRefCount(cmdobj) before the call to Tcl_EvalObjEx and Tcl_DecrRefCount(cmdobj) after it. Since you're using C++, a helper RAII class might make this easier.

Or you could use Tcl_GlobalEval, which these days is just a wrapper around the same underlying basic function but does the Tcl_Obj memory management for you.

std::string cmd = get_itcl_obj_name() + " set_ude_jobname " + name;
if (Tcl_GlobalEval(interp, cmd.c_str()) == TCL_OK) {
    return true;
} else {
    return false;
}

(There are some minor performance differences, but they really don't matter. Or if they did, we'd advise a more substantial rewrite to use Tcl_EvalObjv, but that's a much larger change. Either that or maybe to do some caching of the Tcl_Obj so that Tcl can hang a bytecode compilation off the back-end of it usefully. All of which are quite a lot larger changes than you've got in mind!)

Upvotes: 1

Related Questions