【mark】为何mod性能如此差

        近期接到一个需求，因并发访问单张表导致时延过大，需要拆成10张表，对于ObjID模10来访问对应的表。
        因涉及并发及statement缓存，将原单个字符串sql语句扩展为长度为10的字符串数组，将单个statement缓存扩展为长度为10的statement缓存数组。
        增加开关判断，true时走分表逻辑，false时走原逻辑。

原始代码为

int funcName(long objID,...)
{
    int iRet = getPreparedStatement(m_objStmt, CONST_SQL);
    ......
}

修改为

int funcName(long objID,...)
{
    STMT * stmtTmp;
    const char* pSqlStr;
    if (isSplitTable())
    {
        long step = objID % 10;
        pSqlStr = CONST_SQLSTR_LIST_FOR_SPLIT[step];
        stmtTmp = &(m_objStmtList[step]);
    }
    else
    {
        stmtTmp = &(m_objStmtList[0]);
        pSqlStr = CONST_SQLSTR;
    }
    
    int iRet = getPreparedStatement(*stmtTmp, pSqlStr);
    ......
}

开关关闭时性能和修改前持平，打开时下降明显。

性能下降严重，各种分析、求助无果。
总是有一种感觉，是mod带来的性能下降，于是改为与运算。
重新测试，性能和开关关闭时持平，达到预期效果。

从指令数分析，取模运算和与运算也仅差一个指令，这点差异对应几百万指令简直是九牛一毛，
但是效果却有如此大的差异，至于具体原因，苦思无果，难道触发了蝴蝶效应。。。
领导们和SE们都很怀疑，看到结果也只能事实胜于雄辩了。

const long SPILIT_AND_OPERATION_BASE_NUM = 7;
int funcName(long objID,...)
{
    STMT * stmtTmp;
    const char* pSqlStr;
    if (isSplitTable())
    {
        long step = objID & SPILIT_AND_OPERATION_BASE_NUM;
        pSqlStr = CONST_SQLSTR_LIST_FOR_SPLIT[step];
        stmtTmp = &(m_objStmtList[step]);
    }
    else
    {
        stmtTmp = &(m_objStmtList[0]);
        pSqlStr = CONST_SQLSTR;
    }
    int iRet = getPreparedStatement(*stmtTmp, pSqlStr);
    ......
}

或许可以作为性能优化点，对于2的n次方的取模运算，可以改为2的n次方-1的与运算。