Hi ermouth, thanks for these interesting questions
>> * .info object generation steals 1-2ms even on very powerful machines the only attribute we used so far was the db_name. Is db_name generation slow too? We never used other parameters included in .info. I can only imagine they may be useful at some degrees to: * throw compaction based on some values, even if this should be a lot easier using couchdb auto-compaction * used in connection with js-rewrites to automate e-mail alerts like "used disk quota thresold reach / low on disk" (e.g. using triggerjob). Even in this case, the same may probably be accomplished in other ways (triggerjob + a GET request to _info) This said, if db_name generation isn't too heavy, I'm inclined to say: remove every attributes, but leave db_name >> As for .form object, it seems more reasonable to parse .body right inside Spidermonkey. Moreover, it could be done in lazy manner – using getter proxy. It means .form property in .req object should be defined as a getter function, that parses .body only when .form is accessed. Totally agree. If it has performance impact, .form reconstruction should be left to app developer who exactly knows when he needs it Also I was wondering how heavy could be to include some kind of machine identifier(hostname or ip address of machine running couchdb) inside of the request object? Or if you want to make it even more flexible: how heavy could be to include a configuration parameter inside of the request object? That could be of great help in some N-nodes master-master redunded database configurations, to let one node only(the write node) handle some specific background action. --Giovanni
