gerlowskija commented on code in PR #975: URL: https://github.com/apache/solr/pull/975#discussion_r969971947
########## solr/solrj/src/java/org/apache/solr/common/util/Utils.java: ########## @@ -916,7 +926,10 @@ public static void reflectWrite( } private static List<FieldWriter> getReflectData( Review Comment: There'll definitely be some overhead, but it might be less than you imagine. (Or at least, it was something I was much more worried about until I dug into things a bit more). In particular - once we compute the list of FieldWriter's for a particular class here, we cache it in a static map so we can skip all the reflection-y computation on subsequent calls. That only caches the annotated fields (we can't cache the "unknown/additional properties" stuff as that could change request-to-request). But it's still a huge drop in the number of reflection/introspection calls that happen on a per-request basis. Which should help a good bit? Anyway, I do think we'll want to move away from this in the longer term. As things are converted over to JAX-RS and we build a bigger and bigger library of strongly-typed response objects, maybe it'll become feasible to just rely on Jackson for conversion to all of our formats/media-types? Jackson has deps you can add to handle common formats like XML, and allows extension that we could probably use to cover custom response formats like javabin if we want to. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
