Re: [Xotcl] new methods, request for comment
Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM
From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Sun, 19 Apr 2015 23:25:35 +0200
Am 19.04.15 um 22:21 schrieb Victor Mayevski:
> Recently I encountered a need for two methods in my code:
>
> "info siblings"
> "info root" -- similar to "info parent" but travels down the object
> tree to find the first object or root (of a tree OR a branch).
>
> I realize that it is very trivial to script them in myself but I am
> dealing with thousands (if not millions in the future) of objects and
> would like to squeeze as much performance from the code as possible.
> Hence, I propose to add those methods in C code (to NSF), provided
> that coding them in C will indeed speed things up. Also, having those
> methods seems to be natural, just like having "info parent" or "info
> children".
is this, what you have in mind?
The questionable parts are the ones, where namespaces are used, which do
not correspond
to objects. i would not expect huge differences in performance when
coding this in C.
================================================
package req nx::test
nx::Object public method "info root" {} {
set parent [:info parent]
if {![nsf::is object $parent]} {
return [self]
}
return [$parent info root]
}
nx::Object public method "info siblings" {} {
set parent [:info parent]
set self [self]
set siblings {}
foreach c [info commands ${parent}::*] {
if {[nsf::is object $c] && $c ne $self} {
lappend siblings $c
}
}
return $siblings
}
#
# Some test cases
#
namespace eval ::test {
nx::Object create o
nx::Object create o::p
nx::Object create o::p::q
nx::Object create o::i
nx::Object create o::j
nx::Object create o2
nx::Object create o3
? {o info root} ::test::o
? {o::p::q info root} ::test::o
? {lsort [o info siblings]} {::test::o2 ::test::o3}
? {lsort [o::p info siblings]} {::test::o::i ::test::o::j}
}
================================================
> Another proposal, (tongue-in-cheek, since it probably benefits only my
> code), is to add a timestamp (microseconds) to every object upon
> creation. I have a need to list the object (thousands, if not
> millions) in the order of creation. Again, it is trivial to script it
> in, but performance is an issue.
By adding time stamps to the code, the size of every object will
increase, which we really want to avoid.
How about the following approach. this is like an implementation of
"new" which
uses the creation time as object name. To avoid confusions with digit
overflows,
one needs in the general case a custom sort function, or a "format" for the
name generation, but that should be pretty straight-forward.
#
# Keep order of creation
#
nx::Class create C
for {set i 0} {$i < 100} {incr i} {
C create [clock clicks -microseconds]
}
puts [lsort [C info instances]]
If you use huge trees, i am not sure that using nested tcl namespaces is
memory-wise the best approach - but i do not know the requirements
of your application, and the structure (width, depth, size) of the
object trees.
Maybe it is better to use ordered composites to avoid high number of
namespaces
and huge object names like e.g.:
https://next-scripting.org/xowiki/file/docs/nx/examples/container.html?html-content=1
http://openacs.org/api-doc/procs-file-view?path=packages%2fxotcl-core%2ftcl%2f20-Ordered-Composite-procs.tcl&version_id=4193140&source_p=1
nx/xotcl objects require much less memory when these are namespace-less
(contain no children or per-object methods).
All the best
-g
Date: Sun, 19 Apr 2015 23:25:35 +0200
Am 19.04.15 um 22:21 schrieb Victor Mayevski:
> Recently I encountered a need for two methods in my code:
>
> "info siblings"
> "info root" -- similar to "info parent" but travels down the object
> tree to find the first object or root (of a tree OR a branch).
>
> I realize that it is very trivial to script them in myself but I am
> dealing with thousands (if not millions in the future) of objects and
> would like to squeeze as much performance from the code as possible.
> Hence, I propose to add those methods in C code (to NSF), provided
> that coding them in C will indeed speed things up. Also, having those
> methods seems to be natural, just like having "info parent" or "info
> children".
is this, what you have in mind?
The questionable parts are the ones, where namespaces are used, which do
not correspond
to objects. i would not expect huge differences in performance when
coding this in C.
================================================
package req nx::test
nx::Object public method "info root" {} {
set parent [:info parent]
if {![nsf::is object $parent]} {
return [self]
}
return [$parent info root]
}
nx::Object public method "info siblings" {} {
set parent [:info parent]
set self [self]
set siblings {}
foreach c [info commands ${parent}::*] {
if {[nsf::is object $c] && $c ne $self} {
lappend siblings $c
}
}
return $siblings
}
#
# Some test cases
#
namespace eval ::test {
nx::Object create o
nx::Object create o::p
nx::Object create o::p::q
nx::Object create o::i
nx::Object create o::j
nx::Object create o2
nx::Object create o3
? {o info root} ::test::o
? {o::p::q info root} ::test::o
? {lsort [o info siblings]} {::test::o2 ::test::o3}
? {lsort [o::p info siblings]} {::test::o::i ::test::o::j}
}
================================================
> Another proposal, (tongue-in-cheek, since it probably benefits only my
> code), is to add a timestamp (microseconds) to every object upon
> creation. I have a need to list the object (thousands, if not
> millions) in the order of creation. Again, it is trivial to script it
> in, but performance is an issue.
By adding time stamps to the code, the size of every object will
increase, which we really want to avoid.
How about the following approach. this is like an implementation of
"new" which
uses the creation time as object name. To avoid confusions with digit
overflows,
one needs in the general case a custom sort function, or a "format" for the
name generation, but that should be pretty straight-forward.
#
# Keep order of creation
#
nx::Class create C
for {set i 0} {$i < 100} {incr i} {
C create [clock clicks -microseconds]
}
puts [lsort [C info instances]]
If you use huge trees, i am not sure that using nested tcl namespaces is
memory-wise the best approach - but i do not know the requirements
of your application, and the structure (width, depth, size) of the
object trees.
Maybe it is better to use ordered composites to avoid high number of
namespaces
and huge object names like e.g.:
https://next-scripting.org/xowiki/file/docs/nx/examples/container.html?html-content=1
http://openacs.org/api-doc/procs-file-view?path=packages%2fxotcl-core%2ftcl%2f20-Ordered-Composite-procs.tcl&version_id=4193140&source_p=1
nx/xotcl objects require much less memory when these are namespace-less
(contain no children or per-object methods).
All the best
-g
