7 ms·

Verbosity makes the programmer slower not the program.

raverbashing 7y ago
Yes I understand some verbosity is structural and won't change anything, for example SomeClass x = new SomeClass(); won't make anything slower (ignoring auto for now) Now, I read Java code and I can't help but wonder how things are harder For example, setters and getters, what would be a simple memory write becomes a function call. Not complaining when you actually need it. Reading the examples here (and those are not too bad) https://developer.android.com/reference/java/net/HttpURLConnection https://developer.android.com/reference/java/net/HttpURLConn... it seems you have to actually fight the API to get anything done Why do you need to cast the return of a url.openConnection() to a HttpURLConnection? (I mean, how many connection types exist?)
- pgrulich 7y ago
  So for getters and setters a Jit can inline the function call and in the end you have a direct memory access. In your example you have to cast because URLConnection could be a HttpURLConnection or JarURLConnection. But again a good Jit would speculate that it is always a HttpURLConnection and deoptimize if not.
  - imtringued 7y ago
    The JVM also has full information about the class hierarchy at runtime. If you add a class that overrides a function it will deoptimize that overriden function to a virtual function but otherwise the JVM will just treat it as a static function and inline it if necessary.
- gnosek 7y ago
  > I mean, how many connection types exist? Two? https://developer.android.com/reference/java/net/URLConnection https://developer.android.com/reference/java/net/URLConnecti...
- vips7L 7y ago
  In modern Java I don't see why you would directly use an HttpURLConnection. The stdlib provides an easy to use HttpClient. https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html https://docs.oracle.com/en/java/javase/11/docs/api/java.net....
dgoldstein0 7y ago
It depends. For example, you can verbosely write a loop to copy data from one array to another, or you can use memcpy. The later is typically implemented as hand optimised assembly - it's a pretty small number of operations in x86_64. The former - maybe the compiler optimizes, maybe it doesn't. If it does optimize it, it's definitely more complexity in the compiler and slows it down. In general having some higher level, well optimized helpers can certainly reduce verbosity and increase speed. That said, some types of verbosity just make the programmer write what the compiler would translate to anyway. Or can end up being unnecessary - e.g. a strongly typed language with no inference certain slows the programmer with no effect on the program (though maybe an effect on the type checker).
- im3w1l 7y ago
  A fast memcpy used to be complicated to implement but these days I heard a simple rep movsb will do the trick. This assumes that the source register points to source, destination register points to destination and counter register is set to number of bytes to copy.
  - pizlonator 7y ago
    I wish that was true but my data says it isn't: - A verbose SIMD copy loop is often faster even on modern Intel CPUs that have the more modern rep implementation. - A simple byte copy loop will beat both SIMD and rep when you're copying smaller amounts at a time.

Yes I understand some verbosity is structural and won't change anything, for example SomeClass x = new SomeClass(); won't make anything slower (ignoring auto for now) Now, I read Java code and I can't help but wonder how things are harder For example, setters and getters, what would be a simple memory write becomes a function call. Not complaining when you actually need it. Reading the examples here (and those are not too bad) https://developer.android.com/reference/java/net/HttpURLConnection https://developer.android.com/reference/java/net/HttpURLConn... it seems you have to actually fight the API to get anything done Why do you need to cast the return of a url.openConnection() to a HttpURLConnection? (I mean, how many connection types exist?)

pgrulich 7y ago
So for getters and setters a Jit can inline the function call and in the end you have a direct memory access. In your example you have to cast because URLConnection could be a HttpURLConnection or JarURLConnection. But again a good Jit would speculate that it is always a HttpURLConnection and deoptimize if not.
- imtringued 7y ago
  The JVM also has full information about the class hierarchy at runtime. If you add a class that overrides a function it will deoptimize that overriden function to a virtual function but otherwise the JVM will just treat it as a static function and inline it if necessary.
gnosek 7y ago
> I mean, how many connection types exist? Two? https://developer.android.com/reference/java/net/URLConnection https://developer.android.com/reference/java/net/URLConnecti...
vips7L 7y ago
In modern Java I don't see why you would directly use an HttpURLConnection. The stdlib provides an easy to use HttpClient. https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html https://docs.oracle.com/en/java/javase/11/docs/api/java.net....

dgoldstein0 7y ago

It depends. For example, you can verbosely write a loop to copy data from one array to another, or you can use memcpy. The later is typically implemented as hand optimised assembly - it's a pretty small number of operations in x86_64. The former - maybe the compiler optimizes, maybe it doesn't. If it does optimize it, it's definitely more complexity in the compiler and slows it down. In general having some higher level, well optimized helpers can certainly reduce verbosity and increase speed. That said, some types of verbosity just make the programmer write what the compiler would translate to anyway. Or can end up being unnecessary - e.g. a strongly typed language with no inference certain slows the programmer with no effect on the program (though maybe an effect on the type checker).

im3w1l 7y ago
A fast memcpy used to be complicated to implement but these days I heard a simple rep movsb will do the trick. This assumes that the source register points to source, destination register points to destination and counter register is set to number of bytes to copy.
- pizlonator 7y ago
  I wish that was true but my data says it isn't: - A verbose SIMD copy loop is often faster even on modern Intel CPUs that have the more modern rep implementation. - A simple byte copy loop will beat both SIMD and rep when you're copying smaller amounts at a time.