--- Log opened Tue Aug 17 16:47:24 2004
21:09 < rxr> since I log now, s.th. for our google rating:
21:09 < rxr> The Java programming Language evolved from a language named Oak. Oak was developed in the early nineties at Sun Microsystems as a platform-independent language aimed at allowing entertainment appliances such as video game consoles and VCRs to communicate . Oak was first slated to appear in television set-top boxes designed to provide video-on-demand services.
21:09 < rxr> http://www.engin.umd.umich.edu/CIS/course.des/cis400/java/java.html
21:09 < rxr> ;-)
21:43 < jsaw> hello
21:45 < rxr> hi jsaw !
21:45 < jsaw> hi rxr
21:45 < jsaw> now, what'd you think about cint?
21:47 < rxr> I have not yet had a minute to try it yet
21:47 < rxr> I did normal C++ development with gcc ...
21:47 < rxr> some performance work on my DirIterator did force me to do some profiling on my code ... and thus no free time for the interpreter, yet :-(
21:48 < jsaw> where's the repo, wanna have a look at it... :)
21:48 < rxr> the repo is here:
21:48 < rxr> (but not work readable yet)
21:48 < rxr> (and also not yet that cool code to look at)
21:49 < rxr> http://svn.rocklinux-consulting.de/t2
21:49 < rxr> I'll make it world-readable when more funfamental code is implemented and it is possible to compile packages with the new C++ code ;-)
21:50 < jsaw> just want to see your diriterator, 'cause it sounds interesting
21:50 < rxr> ah - that one is public:
21:51 < rxr> http://svn.rocklinux-consulting.de/gsmp/trunk/utility/include/DirIterator.hh
21:51 < rxr> http://svn.rocklinux-consulting.de/gsmp/trunk/utility/src/DirIterator.cc
21:51 < rxr> but it is still far slower than gnu find ...
21:52 < rxr> example is here:
21:52 < rxr> http://svn.rocklinux-consulting.de/gsmp/trunk/utility/tests/Find.cc
21:52 < rxr> too bad MacOSX recently ruined my gcc34 basedd ROCK system
21:52 < rxr> so I currently have to run the old 2.0.1 release ... :-(
21:53 < rxr> with gcc-3.4 a) the performance would be better and b) profiling should be more accurate ... :-(
21:57 < jsaw> your path name checks in Next() are strange
21:59 < rxr> they are just to filter . and ..
22:00 < rxr> the code just got a bit strange after several performance tweaks ...
22:01 < rxr> I looked into the gnu gind code last night - it is strange ... they do get all pathes in a directory at once - storing them into a big chunk of memory (which they reallocate on grow) and seperate the pathes with \0
22:01 < rxr> an the performance is a lot better then that C++ code :-(
22:01 < rxr> maybe I take the last hours of this day to try some other implementation variants - I want to get near the find performance for normal usage ....
22:01 < jsaw> if (m_entry_name[0] == '.') {
22:02 < jsaw> if ((m_entry_name[1] == 0) || ((m_entry_name[1] == '.') && (m_entry_name[2] == 0)) ) { ... } }
22:03 < rxr> yep you are right ...
22:03 < jsaw> i guess there's also the std::string init problem, running strlen etal...
22:05 < jsaw> probably better to do this check on m_internal_dir_entry->d_name directly
22:06 < jsaw> the DirIterator looks nice and easy I'd say
22:07 < rxr> hm - the .* are rare and I need to return the temprary string object anyway ..
22:07 < rxr> btw, I already put Next and operator++ into the .hh file soe they are inlined and all the temporary object optimized away
22:08 < rxr> unfortunately this did not gave such an big performance gain ...
22:08 < rxr> gprof claims most time is spend in Type for example - but there have been a few other oddities in the gprof output ...
22:08 < jsaw> ? every directory has "." ".." (me wouldn't bet on the optimization...)
22:09 < rxr> yes - but that are only two entries out of many - and only save 2 std::string assignments ...
22:09 < rxr> other places seem to be a bigger bottleneck
22:11 < rxr> if I would have known that even the gnu find does archive such a good performance by just reading all once and stroring them into memory I might have done this in the first place, too
22:12 < rxr> the whole Iterator would have be much easier to do ...
22:13 < jsaw> I was pretty impressed what block wise allocation does to performance -I've heard it before, but I've never tried it...
22:13 < jsaw> until recently
22:17 < jsaw> hrhr - I've spent days to get the gnome build order right, now wtf is that screwed again? (ups sorry - wrong channel :)
22:19 < rxr> hm - I just did an experiment - the ostream output eats so much time (although not shown by gprof)
22:23 < rxr> just removing the output reduced the runtime by 91% ....
22:24 < jsaw> ...
22:24 < rxr> hm - the streams in 3.4 are better coupled with the C streams so these double buffering results do not show up ...
22:25 < rxr> s/results/effects/
22:25 < jsaw> what source documentation system would you recommend?
22:25 < rxr> ouhm - that is a difficult questions
22:25 < jsaw> C source
22:25 < rxr> I only have minimal experience with thosse
22:26 < rxr> valentin: still here? you might have more exp. ...
22:26 < valentin> what ?
22:26 < rxr> most people prefer doxygen - but afaihs it does not handly C++ templates very well ...
22:26 < rxr> valentin: see jsaw question ...
22:26 < rxr> valentin: source documentation system ;-)
22:26 < valentin> oh yes - doxigen
22:26 < rxr> or i even ...
22:27 < rxr> valentin: was it usable? and comments ... ;-)?
22:27 < jsaw> hi valentin
22:27 < valentin> you need to write your own stylesheets if you want it to look cute
22:27 < valentin> hi jsaw
22:27 < jsaw> :(
22:27 < valentin> and it screews up functions with too many templates
22:27 < valentin> but it works and is quite reliable - just try it
22:28 < jsaw> merci
22:28 < valentin> you need special tags in your commens to say what those comments refer to and stuff
22:28 < valentin> just look at their website
22:29 < jsaw> yeah, I know, I used it once, but was looking for another solution that fits better with C.
22:29 < valentin> have to go to bed - my gf gets angry
22:29 < jsaw> For C++ it's pretty good.
22:29 < jsaw> cu valentino
22:29 < valentin> jsaw: if you find sth equaly easy to use, tell me.
22:29 < valentin> gn8
22:30 < rxr> 17.14 0.01 0.01 30240 0.00 0.00 Utility::DirList::Iterator::Type()
22:30 < rxr> 11.43 0.01 0.00 32378 0.00 0.00 Utility::DirList::Iterator::Next()
22:30 < rxr> 11.43 0.01 0.00 30240 0.00 0.00 Utility::File::updateStat()
22:30 < rxr> 11.43 0.02 0.00 1 4.00 4.00 std::basic_string, std::allocator >& std::basic_string 22:30 < rxr> har, std::char_traits, std::allocator >::_M_replace_safe(__gnu_cxx::__normal_iterator 22:30 < rxr> ::char_traits, std::allocator > >, __gnu_cxx::__normal_iterator, std::allocator
22:30 < rxr> > >, char const*, char const*)
22:30 < rxr> this is the top of the profile without output ...
22:31 < jsaw> not a profiled library
22:31 < jsaw> ?
22:32 < rxr> hm?
22:32 < jsaw> libstdc++ is most probably not compiled with -p
22:32 < jsaw> oh that's inline...
22:32 < jsaw> forget my stupidity
22:38 * rxr at evening "lunch"
22:38 < rxr> cu
22:38 < jsaw> bye bye
23:27 < jsaw> gtg, cu
--- Log closed Wed Aug 18 00:00:08 2004