[prev in list] [next in list] [prev in thread] [next in thread] 

List:       scilab-users
Subject:    Re: [Scilab-users] Large variables and execution speeds
From:       Clément David <clement.david () scilab-enterprises ! com>
Date:       2015-03-02 8:33:14
Message-ID: 1425285194.2219.8.camel () scilab-enterprises ! com
[Download RAW message or body]



> By the way, AFAIK, graphical handles are global objects passed by
> reference. Clement, aren't they?

The handle's .data fields are not stored into the stack they can be used
to pass by reference (and the handle act as the reference).

> It is possible to hide some data in their .userdata field ; but it is
> somewhat hacking, and it could be tricky to avoid creating explicitly
> or implicitly local copies of this field's content when working with
> it...
> Creating a pseudo graphic with output driven to "null" and then using
> this hack could extend the test bunch ;) 
> 
> Regards
> Samuel
> 
> Le 24/02/2015 22:38, Tim Wescott a écrit :
> 
> > I have an algorithm that I'm working on that involves having large data
> > sets, which I'm currently representing as tlists.  Due to the
> > constraints of the algorithm, I'm doing many calls that are more or less
> > of the form:
> > 
> > my_tlist = some_function(my_tlist);
> > 
> > The intent is to get the same effect that I would get if I were in C or
> > C++, and wrote:
> > 
> > some_function(& my_structure);
> > 
> > or
> > 
> > my_class.some_function();
> > 
> > It appears, from the significant loss of execution speed when I do this,
> > that Scilab is copying the results of the function into the "my_tlist"
> > variable byte by byte.
> > 
> > At this writing, the only way that I can see to fix this is to invoke
> > the function as:
> > 
> > some_function("my_tlist");
> > 
> > and then wherever I modify data have use an exec function, i.e., replace
> > 
> > local_tlist.some_field = stuff;
> > 
> > with
> > 
> > exec(msprintf("%s = stuff", local_tlist_name));
> > 
> > This seems clunky in the extreme.
> > 
> > Is there another way to do something like this that doesn't force Scilab
> > to copy large chunks of data needlessly, but allows me to operate on
> > multiple copies of similar tlists?
> > 
> > Thanks.
> > 
> 
> _______________________________________________
> users mailing list
> users@lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users


_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[prev in list] [next in list] [prev in thread] [next in thread]