Alon Bar-Lev has posted comments on this change.
Change subject: frontend: Non-plugin automatic invocation of console session
......................................................................
Patch Set 4: (1 inline comment)
....................................................
File
frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/uicommon/SpiceNativeImpl.java
Line 21:
Line 22:
configBuilder.append(lineSeparator).append("type=spice")//$NON-NLS-1$
Line 23:
.append(lineSeparator).append("host=").append(getHost())//$NON-NLS-1$
Line 24:
.append(lineSeparator).append("password=").append(getPassword())//$NON-NLS-1$
Line 25:
.append(lineSeparator).append("port=").append(Integer.toString(getPort()));//$NON-NLS-1$
I don't wish to be read too harsh... but when I read optimization
considerations I always see a red light blinking.
Performance optimization causes code to be less readable/maintainable, it is
worth doing optimization only when proved that a code segment is indeed causes
performance issue.
Most developers tries to pre-optimize their code, producing unmaintainable code
while mostly totally wrong where optimization should be applied.
Some guidelines:
* code that is not called in loop likely won't gain much from optimization.
* code that is user driven likely won't gain much from optimization.
* code that runs within none shared context likely won't gain much from
optimization.
This code is not called in a loop, it is user driven and runs at client side.
In this case optimization only make ugly code and gains nothing.
Not that it is matter for this case, but I give this as an example to potential
of this appearing throughout the application.
In many cases I was involved, developers trying to guess where to optimize
application was a compete failure. The alternate approach was to write the
nicest code possible, run profiler and see where bottle necks are and fix
these. The result is much better quality with less resources, as real issues
are being handled.
Of course senior designers/architects can mark sections of software where
optimization should be taken into account. But this is done under the
visibility of the whole project at hand.
Line 26:
Line 27:
ConsoleModel.makeConsoleConfigRequest(configBuilder.toString());
Line 28: }
Line 29:
--
To view, visit http://gerrit.ovirt.org/11703
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: Ib31e870deb7ecb3dac4cff25e49a3ebca4706a25
Gerrit-PatchSet: 4
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Frank Kobzik <[email protected]>
Gerrit-Reviewer: Alon Bar-Lev <[email protected]>
Gerrit-Reviewer: Frank Kobzik <[email protected]>
Gerrit-Reviewer: Michal Skrivanek <[email protected]>
Gerrit-Reviewer: Tomas Jelinek <[email protected]>
Gerrit-Reviewer: Vojtech Szocs <[email protected]>
_______________________________________________
Engine-patches mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-patches
