--- 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 har, std::char_traits, std::allocator >::_M_replace_safe(__gnu_cxx::__normal_iterator ::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