Why the ATF’s eForms System Sucks

Gotta pay for that cube and health care premium. And the blended rates need to be reasonable market rates, too. You can’t undercut competition too obviously otherwise you run into gifting, bribery, or other issues. Part of the scoring is based upon cost.

You quote the EXCUSE used for the NFA. The REASON was that here in the middle of the Great Depression, the repeal of Prohibition was going to turn a whole slew of Federal agents out of work, an excuse had to be found to keep them employed.

And I agree, we should remember to always, always mention that we want it frickin’ REPEALED!

what?

PHP tries to implicitly convert strings on both sides to numbers if possible when doing the comparison – if that succeeds, they are compared as numbers, otherwise as strings. The rules for conversion are the same as the syntax for number literals in the language, which inherits them from C – so a literal beginning with 0 is interpreted as octal. Now 07 is a valid octal number, and so “07” will be successfully converted to a number and then compared as such, yielding true. On the other hand, 08 is not a valid octal number, and so 8 is converted to string “8”, which is then converted against “08” using string comparison, yielding false.

They all have their little gotchas, don’t they? 😀

Most of my web applications are pretty simple so my needs are simple, too.

Web stuff is just a hobby so I try to use the path of least resistence there.

My main activities are enterprise DBA/engineering and SAN admin. Operations.

Doesn’t that still create a new Foo() each time? o is just a pointer to the heap where each Foo is stored….
public class ttag
{
public static void main(String[] args)
{
Object o;
for(int i =0; i<10;++i)
{
o=new Object();
System.out.println(o);
}
}
}

java.lang.Object@41d5550d
java.lang.Object@1cc2ea3f
java.lang.Object@40a0dcd9
java.lang.Object@1034bb5
java.lang.Object@7f5f5897
java.lang.Object@4cb162d5
java.lang.Object@11cfb549
java.lang.Object@5b86d4c1
java.lang.Object@70f9f9d8
java.lang.Object@2b820dda

I presume the hashcode of a vanilla object is related to address.

In that contrived example, the declaration occurrs in the same statement as the new so more memory (sizeof foo) is consumed rather than using the same memory location. So, if the loop were 100 in the contrived example, we’re talkimg the difference between 100 * sizeof(foo) vs sizeof(foo) being set 100 times.

Another example is

” Hello world “.LTrim().RTrim().Replace(“w”, “W”)

Which has two imtermediate strings vs

” Hello world “.Trim().Replace(“w”, “W”)

Which would have one intermediary string.

Oh, and consider reference counting and GC promotion for finalization for the instances.

I think that new memory is allocated in both cases….

Oh and iirc strings in java are immutable, so String.trim creates a new string, as does string.replace…… so thats 3 vs 2, now what I used to do was
String s=””
for()
{
s+=expression
}
oops new String per iteration

Those are new instance, it’s the reference counting that is impacted, and sent through gc. Compiler optimization tries to take care of tihing, but creating and dangling referencs will accumulate and orce garbage collection. We’re talking rates of creation vs deallocation.

Gene, you’re plainly wrong here. “Foo o” in Java is roughly equivalent to “Foo* o” in C++ – it’s just a pointer on the stack, nothing gets allocated there in either language.

The only thing that does the heap allocation in your example is the “new”, and that one is inside the loop either way, so it’ll allocate the same exact amount of instances.

Furthermore, stack allocation is done entirely on the entrance to the function, and consists of shifting the stack pointer by the predefined (computed at compile time) amount – it doesn’t matter if your “Foo o” is inside the loop or not, the compiler and the JIT know perfectly well that there’s only one “o” in play at a time, so there will only be one slot on the stack for it (or, more likely, it’ll be enregistered).

Also, there’s no reference counting in Java. It uses a mark-and-sweep tracing garbage collector.

Based upon my understanding of Java int19h is right (well he said basically what I said, but still)

For a third solution I like what Mozilla rust is doing memorywise…

As for this
“If you look at amortized time over the runtime of the process, than a typical Java app will actually spend less time allocating/deallocating things than a typical C/C++ app”

I might have to try to find a cite for that, not that I think it is impossible… its just hard to believe a tracing gc can be faster than malloc/free I suppose heap fragmentation could be painful though

Think about what malloc has to do to give you an allocated memory block: it has to find a free space on the heap for that block. Because the heap is fragmented, and because advanced allocators usually use different pools for different-sized objects to reduce that fragmentation, it’s not just a simple “grab N bytes at the end here”; for more convoluted cases, it may even need to do a linear search. Plus there’s the cost of updating the data structure that backs the heap, such as e.g. a tree.

If you think about it on a higher abstraction level, it also sort of makes sense. With a GC, you basically trade memory use (because of non-freed objects hanging around till next GC) for speed. The more memory a GC can waste, the easier it is for it to allocate super-cheap, and the faster it works. So a GC tuned to perform better on average than manual memory management will use several times more memory on average.

This has some links to the papers with numbers (but note that this is for GCs circa 2005; we have better stuff these days):
http://stackoverflow.com/questions/755878/any-hard-data-on-gc-vs-explicit-memory-management-performance

Awesome will read.
As for malloc/free I would imagine
keep a heap/priority queue of unallocated regions by size
keep a hash table of allocated pointers

call malloc() -> take largest region, if it is big enough for data store it there, add pointer to hash, along with memory page etc. Take unused segment add to heap o(logn)
biggest entry too small? Call the os get a new page of memory

Free()-> hash passed pointer, find neighboring blocks o(1), if they are not in use remove neghboring blocks from heap splice together and reheap O(logn)

Gc? well yeah you could defrag the heap, but you can do the same in manual provided the pointers used aren’t the true pointers but point to pointers, so basically a second virtual memory system. (which I imagine gc does)

GC+VM can move the blocks around without an extra pointer indirection, because it can just walk the object graph and update the moved pointers (since it knows where all objects and their fields are).

As for your malloc algorithm, it’s a bit too simplistic because it will often inadvertently use large blocks for small allocations, and subsequently a follow-up large allocation that would fit will now have to use a new page. Hence why they usually maintain several different heaps internally, one for “big” objects, one for smaller stuff etc. If you can move objects around, you can also organize them by lifetime (gen0, gen1 etc), which is also helpful since gen0 is likely to be allocated and deallocated in bulk, so you can try to batch that.

The main perf gain from GC is actually from batching. Basically, your typical C code, a function mallocs on entry, uses that buffer to do whatever it does (say, concat some strings), frees on exit. Every malloc/free pair does all the lookups and heap maintenance separately, even if you call it many thousand times in a loop. OTOH, with a GC, the function allocates (which just advances the “heap top” pointer), and doesn’t free. Then at the end of the loop, the entire allocated memory is freed in one single swipe, with an extra overhead of walking the object graph to determine that this is indeed what should be freed.