Состоит отражение действительно в том, КОТОРЫЕ замедляют это, я не должен использовать его, когда оно имеет смысл к? [дубликат]

Вы можете использовать такой способ ниже, используя ключевые слова rowtype и type для значений whole row и column соответственно:

SQL> set serveroutput on
SQL> declare
    q         varchar2(4000);
    rt        tb1%rowtype;
    i_name    tb1.name%type := 'Mohammad';
    o_surname tb1.surname%type;
begin
    q := 'select * from tb1 t';
    if i_name is not null then
        q := q || ' where ( t.name = :Param1 or :Param1 is null )'; 
    end if;
  execute immediate q into rt using i_name, i_name; 
 -- "i_name" appears twice because of ":Param1" appears twice in the string "q"
  o_surname := rt.surname;
  dbms_output.put_line(rt.surname);
end;

Taleshi

, поскольку есть только один параметр, тогда :Param1 соответствует i_name. Если бы у нас было более одного параметра, то все должно совпадать в порядке появления параметров связывания в строке sql с переменными, разделенными запятыми, такими как i_name, .... в списке using.

18
задан Community 23 May 2017 в 10:28
поделиться

5 ответов

На всякий случай Вы не видите обновление по исходному вопросу: когда Вы отражаетесь для нахождения всех типов, которые поддерживают определенный атрибут, у Вас есть идеальная возможность использовать кэширование. Это означает, что Вы не должны использовать отражение несколько раз во времени выполнения.

Для ответа на общий вопрос отражение медленнее, чем сырые данные скомпилировали вызовы метода, но это очень, намного быстрее, чем доступ к базе данных или файловой системе, и практически все веб-серверы делают те вещи все время.

29
ответ дан 30 November 2019 в 06:02
поделиться

Это много раз быстрее, чем доступ к файловой системе.

Это - многие много раз быстрее, чем доступ к базе данных по сети.

Это - многие многие много раз быстрее, чем отправка ответа HTTP на браузер.

16
ответ дан 30 November 2019 в 06:02
поделиться

Вероятно, Вы даже не заметите его. Всегда представляйте сначала прежде, чем думать об оптимизации.

8
ответ дан 30 November 2019 в 06:02
поделиться

Я задался вопросом то же самое; но оказывается, что отражение не все настолько плохо. Я не могу найти ресурсы (я попытаюсь перечислить их, когда я найду их), но я думаю, что не забываю читать, что это было, возможно, 2x к 3x медленнее. 50% или 33% быстрых все еще быстры.

кроме того, я под капотом веб-формы ASP.net и MVC делают набор отражения, поэтому насколько медленный это может действительно быть?

РЕДАКТИРОВАНИЕ

Вот является одним ресурсом, который я не забываю читать: .Net Reflection и Производительность

4
ответ дан 30 November 2019 в 06:02
поделиться

Хм, я стараюсь избегать отражения, если я могу, но если я должен создать решение, и отражение дает мне изящный способ решить проблему под рукой, я 'll счастливо использую отражение.

, Но, нужно сказать, что я думаю, что отражение не должно использоваться, чтобы сделать 'злые шутки'. В тот самый момент я также работаю над решением, где я использую пользовательские атрибуты для украшения некоторых классов, и да, я должен буду использовать отражение, чтобы знать, ли класс / свойство / независимо от того, что было украшено моим пользовательским атрибутом.

я также думаю, что это - вопрос, 'насколько Вы выполняете отражательные вызовы'? Если я могу, я попытаться кэшировать мои результаты. Как, в решении, где я продолжаю работать: на запуске приложения я осматриваю определенные типы в определенном блоке, были ли те типы украшены моим атрибутом, и, я сохраняю их в словаре.

3
ответ дан 30 November 2019 в 06:02
поделиться