成员订单是否会像在C或C中那样在Java中产生性能差异?

前端之家收集整理的这篇文章主要介绍了成员订单是否会像在C或C中那样在Java中产生性能差异?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在C和C中,不允许编译器重新排序结构的数据成员,因此如果您不小心订购它们,最终会浪费空间.例如:
struct S {
    int i;
    void *p;
    int i2;
};

在具有32位整数和64位指针的平台上,我将首先放置,然后是32位填充,以便p可以进行64位对齐.然后i2占用下一个字的一半,接着是另外32位的填充.结果结构长度为24个字节,而如果首先声明p,则它只有16个字节长.如果阵列中有很多这些结构,找到并删除填充有时可能是一个重要的优化,以节省内存并减少缓存流失.

我很想知道Java是否具有相同的功能.未装箱的类型(例如int和boolean)是否与引用相同或更小?如果它们更小,是否允许编译器重新排序它们以避免插入填充以对齐后续字段?最后,如果是,那么任何编译器都这样做吗?

我现在对此没有特别的优化需求,我只是想知道在选择声明我的字段的顺序时是否应该记住这一点,就像我在C中所做的那样.

解决方法

int类型总是32位,即使在64位JVM中,引用通常也是32位.

在不利方面,Java在每个对象的开头有一个8-12字节的标头,并使用8字节对齐. BTW某些C环境具有16字节对齐.

Are unBoxed types (such as int and boolean) the same size as references or smaller?

对于boolean,byte,char和short,你可以期望它们更小,但是对于long和double,基元可以比引用更大.

And if they’re smaller,is the compiler allowed to reorder them to avoid inserting padding to align subsequent fields?

JIT可以重新组织字段甚至优化它们.

Finally,if it is,do any compilers do this?

javac编译接下来没有优化,查看字节代码将为您提供关于运行时会发生什么的一些线索.无论如何,JIT都可以优化对象中的字段.

I’m just curIoUs to know if I should bear this in mind when choosing what order to declare my fields,like I do in C.

恕我直言,您可以假设您在C中使用的几乎所有优化技巧都不再适用于Java.在为数不多的人中,他们可能并不完全相同.

您应该假设JIT将根据需要优化代码,并使用分析器来确定是否以及何时出现问题.然后才考虑出于性能原因而改变代码.

原文链接:https://www.f2er.com/c/119413.html

猜你在找的C&C++相关文章