[jcifs] Re: jcifs-0.7.10 released
Eric
eglass1 at attbi.com
Fri Jul 4 21:48:40 EST 2003
> Specifically, I want the decoding/encoding technique to be consistent. All
> existing code in the smb package uses decoding/encoding methods that
> pass the object being decoded/encoded, source or destination byte array,
> and the index into that array where the object is being decoded or
> encoded. This is much more efficient than allocting storage with 'new
> byte[..]' encoding your message and then arraycopy-ing that into another
> bigger buffer also allocated dynamically, etc.
Will do. I have a tendency to under-optimize my R & D code (the "if it
ain't broke" fallacy). I'll pick over my stuff when I get a chance.
> jCIFS is not slow so whatever I'm doing can't be too bad. The specific
> examples in your code are using writeUShort(ByteArrayOutputSteam,
> value) which calls ByteArrayOutputSteam.write() for each byte
This isn't actually *too* bad, in theory -- ByteArrayOutputStream
allocates a block internally, and only allocates more when the internal
array is filled; so writing a single byte basically just does an
internal[counter++] = value. I say "in theory", however, because I
neglect to specify an initial capacity when creating the
ByteArrayOutputStream, so it uses the default of 32 bytes (which is way
too small).
> ServerMessageBlock.writeTime()
> could have been used where you encode a 64bit TIME structure in
> NtlmPaswordAuthentication.createBlob().
Wasn't aware of it's existence.
> Also, querying Properties at Runtime is very expensive.
Agreed -- I wasn't sure of the "policy" on this. In most places, jCIFS
reads the props in an initializer (and I think the documentation
indicates properties should be fixed in advance). Some places had them
dynamically read, however, so I didn't know if I should be handling
cases in which the user does a setProperty mid-execution. Doing them at
init time is definitely preferable.
>
> I'm happy to see you working in the SMB layer but I have to enforce my
> coding standards in there. I realize that in many cases efficiency is not
> very important but if it effects something that happens very frequently
> (like every SMB) could have a noticable impact on performace. I'd like
> to see you use the same techniques in all the packages but if it's mosty
> your code I would be a fool to complain considering you're knowledge of
> HTTP and all the web service stuff that I'm clueless about.
>
I don't consider constructive criticism "complaints" -- I obviously want
to end up with the best product, and input/feedback are essential to the
process. That's why I send out updates piecemeal (rather than
submitting pre-built release packages with my changes included, as was
previously offered); as you are the lead on jCIFS, I consider it your
right and privilege to perform the final review on all my submissions
before inclusion. The *last* thing I want to do is sacrifice quality
for features.
I'll go through and do some auditing of my stuff (both the new and the
old) and look for opportunities for optimization. Thanks!
Eric
More information about the jcifs
mailing list