> If they're inlined they don't have ANY overhead. That's what I thought, but the guy here said he's seen assembly code which has overhead. Maybe a non-compliant C compiler?
> Second guessing compilers is a bad idea. Yes, but let's say you want to divide by 8 in performance code. Me, I'm inclined to just do that and trust the compiler to make it a shift-3, but actually I might check once (looking at assembly code) to insure it's that smart. > Well, what are you using K&R C? You should always be compiling with > C++, EVEN if you're writing C for some unknown reason. Actually it's C++, but still an offbrand compiler in the local context. > jset_gt ( find > key in Judy Set ) > jmap_le ( find key <= in Judy Map) Hmm... That might have worked. > I actually mess up "JudyFirst" regularly because I keep thinking it is > like STL.begin() -- finds the first key in the container. But it > doesn't. It finds the first key >=, you have to initialise the key > with 0 to find the first key in the container. I use the C interfaces > not the MACRO interface and there's no documentation there. The docs > are with the MACROS I don't use. Yeah, sorry, there were better manual entries for the functions, once upon a time. Alan ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Judy-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/judy-devel
