Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Is it possible to avoid array zeroing/initialization in Java?
I need to quickly allocate fresh byte arrays of fixed length that will completely be filled with predefined data. Therefore, I don't need the JVM to automatically zero the array on instantiation and I certainly don't mind if the array contains junk. All I need is constant time array allocation, which unfortunately becomes O(n) due to the mentioned zeroing issue.
Would using unsafe help?
JVM always initializes arrays. But you can reuse the same array and it will be initialized once.
The class sun.misc.Unsafe is officially undocumented.
From http://mishadoff.com/blog/java-magic-part-4-sun-dot-misc-dot-unsafe/
Avoid initialization
allocateInstance method can be useful when you need to skip object
initialization phase or bypass security checks in constructor or you
want instance of that class but don't have any public constructor.
Some resources indicate its removal from Java 9.
What kind of application do you have that array initialization became a performance bottleneck?
In response to "Sadly I can't because these arrays are held on to for an undefined period of time by an asynchronous networking library. Reusing them results in overwriting partially unsent messages.":
Then use a pool and reuse only arrays that are not currently in use. You will have to manage that, though. So, is array creation really that much of an issue?
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I want to run a method at program shutdown which requires a temp variable to an object reference to be stored. I just so happen to have a class variable of the same type that I've been using this whole time to store the current value, and it's no longer needed.
I know it's probably not best practice, but if I want to save the extra step and write an object reference as a placeholder while my program does some housekeeping, would it be faster to write it to this variable which already exists than to declare a fresh temp from scratch? The static variable is in another class, if that makes a difference.
"So fast it doesn't matter," and either way an object gets written. I'm just trying to understand how these things work in memory. The glaring issue with a new variable seems to me that it's a declaration which has to allocate some space on the disk.
Reusing some unrelated class variable is the worst choice. It makes your code unreadable and unmaintainable.
Allocating an additional reference variable on the stack also doesn't take time - it doesn't matter whether your method has 5 or 50 local variables. Allocating local variables means just adding/subtracting some (constant) value from the stack pointer.
Forget about allocating space on the disk - the state of your running program is normally not written to the disk at all.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Why does Java not support a nice and readable direct print-out for arrays?
I do know that Arrays.toString can be used to get that, and I also know what the hashcode output means (as explained in Why does the toString method in java not seem to work for an array).
But I am asking myself why the developers did not choose to make arrays directly print the readable representation.
Is it technically impossible? Would it impact performance?
arrays in java are a special case. There is no java source code for an array class and arrays are implemented in the JVM directly.
Given that, arrays don't have any methods themselves and they do not override any of the default Object methods (Yeah they're treated as objects but they're handled with special bytecodes).
As for why the decided to do that it probably has to do with allowing more flexibility with creating arrays of different types and dimensions, maybe processing speed as well.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I just have a question regarding code reusability in method return type.
In Java 8 there is the concept of collectors where the user will specify the type of collection the stream would return.
would it be beneficial if base retrieval methods accept the Collector parameter instead of returning a predefined Collection, say list.
the method with the predefined Collection will then pass the Collectors.toList() to the base retrieve method.
Because java.util.stream.Stream provides the functionality that you describe, there's little reason for any other class to do the same: instead of taking a Collector, collecting a stream into it, and returning the result, it makes much more sense to just return the stream to begin with: it's clearer, and it gives the caller much more flexibility than just the choice of collection type.
That said, in most cases you're better off just returning an appropriate collection type. You usually have a better sense than your clients of what collection-types make sense for a given API, and your clients don't usually care that much unless there's some reason that they would want to mutate the collection afterward. If you just return a Stream, you're giving your clients less information about what to expect (unless you then compensate for it by putting the information in the Javadoc, that they then have to read and make sense of).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Is it considered bad practice to use a method that returns an object as a parameter? I have the following method:
public static boolean checkForBlanks(PageDescription pageDesc){
// do some stuff
}
And this method is called within another method:
checkForBlanks(aPage.getPageDescription());
Is it better practice to create a PageDescription object using the getPageDescription method first, then pass that as a parameter(The checkForBlanks methods will check a number of fields on this object) or is there any advantage to be had with the current implementation?
The PageDescription object is not used anywhere else in the calling method, so it is used explicitly in the checkForBlanks method only.
Since the instance returned by aPage.getPageDescription() is only used once within your method, there is no advantage in assigning aPage.getPageDescription() to a variable prior to passing it to checkForBlanks().
In such cases it is simply a matter of preference. I don't like the concept of tieing the hands behind the back in order to fit some misguided concept of code.
In general I prefer the idea of good looking code is good.
checkStuff(storage.getEntry()); is a easy line of good that is clear and everyone can easily follow it.
World.getSomething().doStuff(Storages.getStorage(key).getEntry()); is for example less clear to read.
Keep it clean and simple. That is the best way to go by it. If you look a week later at your code and have no clue what the heck you did, then you did something wrong.
Good code is in the end:
Have fun coding.
you should go with this (good);
checkForBlanks(aPage.getPageDescription());
instead of this (bad):
PageDescription pageDescription = aPage.getPageDescription();
checkForBlanks(pageDescription);
pageDescription in the second variant is an unnecessary local variable because there is no value read from afterwards. So you blow up your code (okay, just one line), and it will cost CPU time and Memory consumption for creating the object. Both is not needed.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Kryo is really fast and small. what's the secret here?
I have diving into its code for a while, but still need some guidance.
Thanks.
From their page:
The 2.22 release fixes many reported issues and improves stability and
performance. It also introduces a number of new features, most notably
that it can use Unsafe to read and write object memory directly. This
is the absolute fastest way to do serialization, especially for large
primitive arrays.
It uses direct bytecode-level access to the fields - sun.misc.Unsafe or ASM library. Kryo was fast even before introducing unsafe usage. The general answer, I think, is that performance is their highest priority. Java's reflection is not that slow when used carefully - i.e. when the java.lang.Field and java.lang.Method are cached. I set up an experiment which sorted an array with two different comparators - one was using direct field access and the other was using cached fields. There was only 2x difference, which means unnoticeable in context with IO.
FieldSerializer:
By default, most classes will end up using FieldSerializer. It
essentially does what hand written serialization would, but does it
automatically. FieldSerializer does direct assignment to the object's
fields. If the fields are public, protected, or default access
(package private), bytecode generation is used for maximum speed (see
ReflectASM). For private fields, setAccessible and cached reflection
is used, which is still quite fast.